Re: pg17.3 PQescapeIdentifier() ignores len - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: pg17.3 PQescapeIdentifier() ignores len
Date
Msg-id Z7DNabPmLZwYg5T2@msg.df7cb.de
Whole thread Raw
In response to Re: pg17.3 PQescapeIdentifier() ignores len  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Re: Andres Freund
> I think that'd be *really* helpful. Of course that does require somebody
> watching and raising an alarm...
> 
> Do you have ongoing package builds for sid or such?

What I am doing anyway is to trigger the regression test of each
package once a month (randomly distributed over the month so I'm not
getting swamped with failures) and then try to keep this page as
"green" as possible:

https://jengus.postgresql.org/view/Testsuite/

> Are there regular outomated rebuilds that could tell us of such a problem
> between the release being stamped and actually made?

The current proposal would be to simply build the minor releases from
the Monday tarballs, do the extended testing on Tuesday/Wednesday by
triggering all tests from that Jenkins page, and hopefully complain
before Thursday.

There are daily builds of all PG server branches, but
1) there are too many temporary failures so I don't have enough time to chase them
2) these packages are not used as basis for regression testing the other packages

https://jengus.postgresql.org/view/Snapshot/

1) might improve once the networking (hello arm64) and IO (hello
s390x) issues of some of the build machines are fixed.

2) might be something we should give a try. Either it works, or it
turns out there are too many weird minor-version-skew problems that
aren't actual bugs.

It would still not catch any last-minute regression from security
patches, though.

Christoph



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg17.3 PQescapeIdentifier() ignores len
Next
From: Tom Lane
Date:
Subject: Re: Decision by Monday: PQescapeString() vs. encoding violation