JDBC error: Unexpected packet type: 25

[Ignacio Rey]

Hello,

I'm sometimes getting this error from the PostgreSQL JDBC driver 
(version 42.2.10):


java.io.IOException: Unexpected packet type: 25

(Full stack trace at the end of this message).

Looks a lot like a bug or a version mismatch. The latter is unlikely 
since the driver is relatively new but the server is a bit older (11.4). 
If it were a bug I would expect more people to reproduce it, but I 
haven't found anything on google (the only result is not even about 
PostgreSQL).


For the moment I have no idea how to reproduce this error. It appears to 
happen just randomly.


I'd like to know if someone can suggest a way to gather more information 
so I can eventually turn it into reproducible steps and fill a bug report.


Also, can pg_bouncer be related?

Thanks.
Ignacio


Stack trace:

org.hibernate.TransactionException: commit failed
at 
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:185) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]


(8 stack frames of custom application software omitted)

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[?:1.8.0_191]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
[?:1.8.0_191]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
[?:1.8.0_191]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
[?:1.8.0_191]

at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
Caused by: org.hibernate.TransactionException: unable to commit against 
JDBC connection
at 
org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doCommit(JdbcTransaction.java:116) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]
at 
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:178) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]

... 13 more
Caused by: org.postgresql.util.PSQLException: An I/O error occurred 
while sending to the backend.
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:338) 
~[postgresql-42.2.10.jar:42.2.10]
at 
org.postgresql.jdbc.PgConnection.executeTransactionCommand(PgConnection.java:829) 
~[postgresql-42.2.10.jar:42.2.10]
at org.postgresql.jdbc.PgConnection.commit(PgConnection.java:851) 
~[postgresql-42.2.10.jar:42.2.10]
at 
org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doCommit(JdbcTransaction.java:112) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]
at 
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:178) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]

... 13 more
Caused by: java.io.IOException: Unexpected packet type: 25
at 
org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2395) 
~[postgresql-42.2.10.jar:42.2.10]
at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:311) 
~[postgresql-42.2.10.jar:42.2.10]
at 
org.postgresql.jdbc.PgConnection.executeTransactionCommand(PgConnection.java:829) 
~[postgresql-42.2.10.jar:42.2.10]
at org.postgresql.jdbc.PgConnection.commit(PgConnection.java:851) 
~[postgresql-42.2.10.jar:42.2.10]
at 
org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doCommit(JdbcTransaction.java:112) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]
at 
org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:178) 
~[hibernate-core-4.1.4.Final.jar:4.1.4.Final]

... 13 more


=> select version();
 version 


-
 PostgreSQL 11.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 
20150623 (Red Hat 4.8.5-36), 64-bit

(1 row)

Re: JDBC error: Unexpected packet type: 25

[Vijaykumar Jain]

" java.io.IOException: Unexpected packet type: 25"

char 25 is EM. ( End of Medium)
I do not see it being part of the wire protocol, as for the same reason,
not in pgjdbc handling i think.

PostgreSQL: Documentation: 13: 52.7. Message Formats

pgjdbc/QueryExecutorImpl.java at REL42.2.10 · pgjdbc/pgjdbc (github.com)


I may be diverting that may not be related but a few things, just in case.
1) we once had a scenario of a bad nic driver e1000, that resulted in a lot
of pkt losses.
We figured out there were too many pkt drops and upgraded the driver to
vmnet or something.

2)You should also raise the same with pgjdbc. I see they have resolved
issues with other mismatched packet types like 52 at their end.

3) I have had some arguments wrt pgjdbc/npgsql having issues with pgbouncer
and not with postgresql directly. I counter by running the same queries
using psql  with pgbouncer. never got an error. But I am not an expert with
Java so I keep an open mind and also raise this with the driver owners just
in case as well as pgbouncer. else it is a deadlock :)

Unexpected packet type during stream replication · Issue #1466 ·
pgjdbc/pgjdbc (github.com) 
although this one is different issue, can you reproduce this case like
above ?

Re: bottom / top posting

[Jan Wieck]

On 6/7/21 5:40 PM, Joshua Drake wrote:
At least the students haven't discovered this list yet and are posting 
their homework assignments (like they do on chat channels).


You forgot to mention that they are posting their homework assignments 
as cellphone pictures taken from half broken implementations in whatever 
GUI they are using.



Regards, Jan

--
Jan Wieck
Postgres User since 1994

How to pass a parameter in a query to postgreSQL 12

[Hassan Camacho Cadre]

Hello


I recently installed a postgreSQL v12, in previous version 8.3 in all my
queries I pass parameters using the character :

SELECT

  public.tabla.id

FROM

  public.tabla

WHERE

  public.tabla.id = :a

In the new version when I try to make this query it sends me an error

ERROR syntax error at or near ":"



I tried



?a , ¿a, @a



But I always got an error


I am executing this query on the query editor of pgadmin 4

Could someone help me to know how I can configure the parameter passing
character or, failing that, how I should pass the parameters in this new
version.

Greetings

-- 
Atentamente Msc. Hassan Camacho.

Re: bottom / top posting

[Dean Gibson (DB Administrator)]

On Mon, Jun  7, 2021 at 07:53:30PM +0200, Francisco Olarte wrote:

... properly scanning a top posted one takes much longer.


Not here.


I find top-posting moderately offensive, like saying "I am not going to waste time 
to make your reading experience better".


Not here either.

Top-posting has been the predominantly common practice in the business & 
government world for decades, & it is easy to adapt to.  Just like HTML 
eMail (within reason) & more than 80 columns on a line.  Somehow, 
millions of ordinary people are able to adapt to this, on very popular 
network eMail providers, like Google groups & groups.io, as well as 
their work environment.


I suppose it comes from the practice in those environs when paper memos 
were the norm, & if you needed to attach the contents of other paper 
memos to your own for context, you stapled them to the BACK of your own.


Of course, wherever (top/bottom) one posts, trimming is important, but 
it's far less important with top-posting.  You usually don't have to 
scroll down to get the immediate context, & if you do, you have less far 
to scroll.


I wonder about the tolerance of the world we live in.  Somehow, I can 
deal with top-posting, bottom-posting, middle-posting, HTML eMail, 
straight-text eMails, 80-column eMails, variable-width eMails, 
occasional ALL CAPS eMails, & stupid multi-line signatures, all without 
getting my tail in a knot over it.


But then, I was VERY successful in my software development career, 
consulting at about 30 companies (now retired).  Maybe working with 
others without conflict on silly issues, had something to do with it.


This message would normally have been top-posted, but was bottom-posted 
to avoid offending or irritating people here. Seriously.


ps:  The people on this list have been very helpful, despite the above.

Re: bottom / top posting

[Tom Lane]

"Dean Gibson (DB Administrator)"  writes:
> Top-posting has been the predominantly common practice in the business & 
> government world for decades, & it is easy to adapt to.

The reason why the old-timers around here are sticky about this is that
we believe we are writing for the mailing list archives.  Gmail-style
quoting is indeed the appropriate amount of effort for throwaway threads
that only a few people will read and (probably) none of them will consult
again later.  But for threads that (a) will be read by hundreds or
thousands of people right now, and (b) will be searched for in the project
archives some unknowable number of times in future, it is worth spending
extra effort to make the conversation easy to follow.

I realize that a lot of posters to these lists can't be bothered to
save a few seconds of my time.  That's fine; I tend to stop reading
their messages right away.

regards, tom lane

Re: bottom / top posting

[Tom Browder]

On Wed, Jun 9, 2021 at 17:05 Tom Lane  wrote:

> "Dean Gibson (DB Administrator)"  writes:
> > Top-posting has been the predominantly common practice in the business &
> > government world for decades, & it is easy to adapt to.


But it sure adds to the digital clutter!

The reason why the old-timers around here are sticky about this is that
> we believe we are writing for the mailing list archives.  Gmail-style


I agree wholeheartedly, Tom.

>
I realize that a lot of posters to these lists can't be bothered to
> save a few seconds of my time.  That's fine; I tend to stop reading
> their messages right away.


Ditto.

Best regards,

-Tom Browder

Re: bottom / top posting

[Dave Cramer]

> The reason why the old-timers around here are sticky about this is that
> we believe we are writing for the mailing list archives.  Gmail-style
> quoting is indeed the appropriate amount of effort for throwaway threads
> that only a few people will read and (probably) none of them will consult
> again later.  But for threads that (a) will be read by hundreds or
> thousands of people right now, and (b) will be searched for in the project
> archives some unknowable number of times in future, it is worth spending
> extra effort to make the conversation easy to follow.
>
>

So on this page PostgreSQL mailing lists
 there is no mention of  top/bottom
posting,
One has to go to Mailing Lists - PostgreSQL wiki
 to find the etiquette.

Seems to me that adding a link to the wiki on the first link makes sense as
well as possibly adding it to the subscription message

Dave

>
>

Re: bottom / top posting

[Adrian Klaver]

On 6/9/21 2:41 PM, Dean Gibson (DB Administrator) wrote:



On Mon, Jun  7, 2021 at 07:53:30PM +0200, Francisco Olarte wrote:

... properly scanning a top posted one takes much longer.




I wonder about the tolerance of the world we live in.  Somehow, I can 
deal with top-posting, bottom-posting, middle-posting, HTML eMail, 
straight-text eMails, 80-column eMails, variable-width eMails, 
occasional ALL CAPS eMails, & stupid multi-line signatures, all without 
getting my tail in a knot over it.




Think of it as a conforming to a style guide when writing for a 
publication. In this case the style is preferred for the reasons Tom 
Lane stated in his post.



--
Adrian Klaver
adrian.kla...@aklaver.com

PostgreSQL replication lag - Suggestions and questions

[Lucas]

Hi,

I have a cluster of PostgreSQL 9.2.21, where there is one master and one slave 
with streaming replication.
I have few points and questions about the replication, and was hopping you guys 
could share your opinions, suggestions and experiences.

> Before I start; Yes! I know... PG 9.2? Really? Well... we're working on a 
> migration project.. We're considering either EnterpriseDB or RDS (we're 
> already in EC2 instances in AWS).

My current architecture is: master (AZ1) --> read slave (AZ2) --> hot-standby 
(AZ2) - They are all using streaming replication.

All read-only queries are sent to the read slave. Sometimes the replication lag 
between the master and the slaves reaches up to 10 minutes. I understand that 
the lag is expected in any replication scenario, and below you can find some 
suggestions that I think would help to minimize the lag time.

-   Having the read slave in the same AZ as its master - for better network 
throughput;
-   Having the latest PostgreSQL version to get its best performance

-   For the replication, we use Streaming Replication. A native PostgreSQL 
solution that was first introduced in PostgreSQL 9.0 version.

-   So, that means that we are using its very very early version. Many 
improvements have been introduced since 9.x which we’re not taking advantage of.

-   Having the latest Operational System behind PostgreSQL to get its best IO 
performance

-   We’re still on Ubuntu 16.04.2 for both Master and Slaves. Again, a lot of 
performance improvements were introduced in the new Ubuntu version 20.x, which 
we’re not taking advantage of.

-   Consider changing the read slave to be synchronous and not asynchronous
-   Consider having multiple slaves and not just one big instance
-   Consider spreading the load between the master and the slaves with a 
Pooling software (PGPOOL)

-   Currently this is done at the application level (PHP)
-   The master should also do read-only queries. Why not?

Do you agree?
Do you have any other suggestions?
Is there anything I could do now to minimize the replication lag, or since 
we're working on a migration there is no point wasting our time?

---
Regards,

Lucas

> This message is encrypted. Both the Public Key and the GPG encrypted message 
> are included in this email so that you can verify its origin.

publickey - root@sud0.nz - 0xC5E964A1.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Re: bottom / top posting

[Adrian Ho]

On 7/6/21 8:05 pm, Vijaykumar Jain wrote:

I hear a lot of suggestions wrt bottom / top posting.


To be pedantic, the preferred posting style seems in fact to be *inline 
trim-posting*, i.e.


* your responses are immediately below the text you're replying to, so 
the context is immediately apparent


* anything not relevant to your response is removed

Pure bottom-posting seems to be acceptable too, but if you're responding 
to multiple quotes, inline posting is *much* friendlier to the reader.


--
Best Regards,
Adrian

Re: bottom / top posting

[Steve Litt]

Dean Gibson (DB Administrator) said on Wed, 9 Jun 2021 14:41:47 -0700

>> On Mon, Jun  7, 2021 at 07:53:30PM +0200, Francisco Olarte wrote:  
>>> ... properly scanning a top posted one takes much longer.  
>
>Not here.

Depends on whether the top-poster reiterates nouns instead of just
using pronouns, and whether he/she identifies what is being responded
to. Most don't. Hence the frustration.

>
>>> I find top-posting moderately offensive, like saying "I am not
>>> going to waste time to make your reading experience better".  
>
>Not here either.
>
>Top-posting has been the predominantly common practice in the business
>& government world for decades, & it is easy to adapt to.  

OF COURSE! In business you need the CYA of having the entire discussion
archived, and often the discussion is between two people. But a mailing
list is a mind-meld of tens or hundreds of people. Placing the response
directly below the text that prompted the response makes everything
crystal clear. But just one top-poster can blow up that whole clarity
for the remainder of the thread, making everything a data mine through
posts and guessing who meant what.



> Just like
>HTML eMail (within reason) & more than 80 columns on a line.  Somehow, 
>millions of ordinary people are able to adapt to this, 

in business contexts


> on very popular 
>network eMail providers, like Google groups & groups.io, as well as 
>their work environment. 

Yeah, google, microsoft and the rest of the
big boys make it much easier to top post. If they made interleave
posting easier, you'd be arguing for that right now, in all contexts
except businss.

>I suppose it comes from the practice in those environs when paper
>memos were the norm, & if you needed to attach the contents of other
>paper memos to your own for context, you stapled them to the BACK of
>your own.
>
>Of course, wherever (top/bottom) one posts, trimming is important,

Thank you!

People see mile long emails and blame interleave or bottom posting, when
what's to blame is a failure to remove material not germane to the
current responses. Have you ever noticed these guys who write their
last line, then leave a couple thousand lines of previous stuff, not at
all apropos to the current post, so you have to read thru all that
stuff to make sure there's nothing else? This isn't about bottom
posting, it's about laziness and/or not understanding communication.
 
>it's far less important with top-posting.  You usually don't have to 
>scroll down to get the immediate context, 

:-) The top-posted emails you and I have read must be incredibly
different. I usually find top-posts require an archaeological dig
through layers of emails past.

[snip]

>
>But then, I was VERY successful in my software development career, 
>consulting at about 30 companies (now retired).  Maybe working with 
>others without conflict on silly issues, had something to do with it.

I find nothing silly about clarity or the lack thereof. Imagine the
problems a project could face because person A was too lazy to
interleave post, and person B was tolerant of it and didn't ask enough
"what do you mean by" questions.

>
>This message would normally have been top-posted, but was
>bottom-posted to avoid offending or irritating people here. Seriously.

Thanks! Your message was crystal clear and easy to respond to.

SteveT

Steve Litt 
Spring 2021 featured book: Troubleshooting Techniques of the Successful
Technologist http://www.troubleshooters.com/techniques