On Thu, Aug 13, 2020 at 01:29:35AM -0400, Tom Lane wrote:
> Well, "you get a compiler warning" isn't a reason to consider the version
> unsupported. There are probably going to be a few other warnings you get
> when building on an ancient platform --- as long as it works, I think
> we're fine.
Michael Paquier writes:
> On Wed, Aug 12, 2020 at 10:50:21PM -0400, Tom Lane wrote:
>> Ummm ... aren't you going to get some cast-away-const warnings now?
> Let me see.. The function signatures we use have been visibly changed
> in 9eb9c932, which comes down to a point between 2.2.2 and 2.3,
On Wed, Aug 12, 2020 at 10:14 PM Tom Lane wrote:
>
> Noah Misch writes:
> > ... Another advantage of master-only is a guarantee against
> > disrupting time-critical patches. (It would be ugly to push back branches
> > and
> > sort out the master push later, but it doesn't obstruct the mission.)
On Wed, Aug 12, 2020 at 10:50:21PM -0400, Tom Lane wrote:
> Ummm ... aren't you going to get some cast-away-const warnings now?
> Or are all of the called functions declared as taking "const char *"
> not just "char *"?
Let me see.. The function signatures we use have been visibly changed
in
On Thu, Aug 13, 2020 at 01:14:33AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > ... Another advantage of master-only is a guarantee against
> > disrupting time-critical patches. (It would be ugly to push back branches
> > and
> > sort out the master push later, but it doesn't obstruct the
Noah Misch writes:
> ... Another advantage of master-only is a guarantee against
> disrupting time-critical patches. (It would be ugly to push back branches and
> sort out the master push later, but it doesn't obstruct the mission.)
Hm, doesn't it? I had the idea that "git push" is atomic ---
Hi
čt 13. 8. 2020 v 6:31 odesílatel Mikhail Titov napsal:
> Hello!
>
> According to the docs[1], one may use DEFAULT keyword while inserting
> into generated columns (stored and identity). However, currently it
> works only for a single VALUES sublist with DEFAULT for a generated column
> but
Thomas Munro writes:
> Makes sense. I tested this version on a primary and a replica and
> verified that parallel workers launch, but I saw that autovacuum
> workers still can't start without something like this:
> @@ -2463,7 +2463,8 @@ canAcceptConnections(int backend_type)
> * be
On Thu, Aug 13, 2020 at 2:37 PM Tom Lane wrote:
> I experimented with separating the shutdown-in-progress state into a
> separate variable, letting us actually reduce not increase the number of
> pmStates. This way, PM_RUN and other states still apply until we're
> ready to pull the shutdown
On Wed, Aug 12, 2020 at 07:52:42PM -0400, Alvaro Herrera wrote:
> Yeah. As I understand, the only reason to have this number is to avoid
> an arbitrarily large number of entries created as a single multi-insert
> WAL record ... but does that really ever happen? I guess if you create
> a table
Hi all,
While working on support for REINDEX for partitioned relations, I have
noticed an old bug in the logic of ReindexMultipleTables(): the list
of relations to process is built in a first transaction, and then each
table is done in an independent transaction, but we don't actually
check that
Hello!
According to the docs[1], one may use DEFAULT keyword while inserting
into generated columns (stored and identity). However, currently it
works only for a single VALUES sublist with DEFAULT for a generated column
but not for the case when VALUES RTE is used. This is not being tested
and it
On Thu, Aug 13, 2020 at 12:08:36AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
> >> If the workflow is commit first and re-indent later, then we can always
> >> revert the pgindent commit and clean things up manually; but an auto
> >>
Noah Misch writes:
> On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
>> If the workflow is commit first and re-indent later, then we can always
>> revert the pgindent commit and clean things up manually; but an auto
>> re-indent during commit wouldn't provide that history.
> There are
On Wed, Aug 12, 2020 at 07:47:01PM -0400, Tom Lane wrote:
> Jesse Zhang writes:
> > On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
> >> Is there any reason we don't just automatically run pgindent regularly?
> >> Like once a week? And also update typedefs.list automatically, while
> >>
On Wed, Aug 12, 2020 at 6:06 PM Thomas Munro wrote:
> [patch]
Bitrot, rebased, no changes.
> Yeah, the combined effect of these two patches is better than I
> expected. To be clear though, I was only measuring the time between
> the "redo starts at ..." and "redo done at ..." messages, since
Hello,
I'm not sure if I should have posted this to pgsql-advocacy, but this is being
developed so I posted here.
Does anyone know if this development come to open source Postgres, or only to
the cloud services of Microsoft and Google?
(I wonder this will become another reason that Postgres
On Wed, Aug 12, 2020 at 09:12:07AM +0200, Peter Eisentraut wrote:
> There are two ancient hacks in the cygwin and solaris ports that appear to
> have been solved more than 10 years ago, so I think we can remove them. See
> attached patches.
+1 for removing these. >10y age is not sufficient
Michael Paquier writes:
> Per the following commit in upstream SELinux, security_context_t has
> been marked as deprecated, generating complains with
> -Wdeprecated-declarations:
> https://github.com/SELinuxProject/selinux/commit/7a124ca2758136f49cc38efc26fb1a2d385ecfd9
Huh. Apparently it's
Thomas Munro writes:
> On Thu, Aug 13, 2020 at 10:21 AM Tom Lane wrote:
>> Also, the state before PM_WAIT_READONLY could have been
>> PM_RECOVERY or PM_STARTUP, in which case we don't really want to think
>> it's like PM_HOT_STANDBY either; only the BgWorkerStart_PostmasterStart
>> case should
On Wed, Aug 12, 2020 at 06:53:25PM -0400, Alvaro Herrera wrote:
> On 2020-Aug-12, Andres Freund wrote:
>> Is there any reason we don't just automatically run pgindent regularly?
>> Like once a week? And also update typedefs.list automatically, while
>> we're at it?
>
> Seconded.
Thirded.
--
Hi all,
Per the following commit in upstream SELinux, security_context_t has
been marked as deprecated, generating complains with
-Wdeprecated-declarations:
https://github.com/SELinuxProject/selinux/commit/7a124ca2758136f49cc38efc26fb1a2d385ecfd9
This can be seen with Debian GID when building
On Wed, Aug 12, 2020 at 5:39 PM Andres Freund wrote:
> Attached. Needed one python3 fix, and to be adapted so it works with
> futex based semaphores. Seems to work for both sysv and posix semaphores
> now, based a very short test.
Great, thanks!
--
Peter Geoghegan
Hi,
On 2017-06-22 14:08:45 -0700, Andres Freund wrote:
> At pgcon some people were talking about the difficulty of instrumenting
> the time actually spent waiting for lwlocks and related measurements.
> I'd mentioned that linux these days provides infrastructure to measure
> such things in
Hi,
On 2020-08-12 16:47:13 -0700, Peter Geoghegan wrote:
> On Mon, Aug 10, 2020 at 5:41 PM Andres Freund wrote:
> > Most of the cases where this kind of information really is interesting
> > seem to benefit a lot from having stack information available. That
> > obviously has overhead, so we
Andres Freund writes:
> Unfortunately that is, with the current tooling, not entirely trivial to
> do so completely. The way we generate the list of known typedefs
> unfortunately depends on the platform a build is run on. Therefore the
> buildfarm collects a number of the generated list of
On 2020-Aug-11, Robert Haas wrote:
> On Tue, Aug 11, 2020 at 1:59 AM Michael Paquier wrote:
> > On Mon, Aug 10, 2020 at 05:32:21PM -0700, Andres Freund wrote:
> > > Do we really want to end up with several separate defines for different
> > > type of catalog batch inserts? That doesn't seem like
On Mon, Aug 10, 2020 at 5:41 PM Andres Freund wrote:
> Most of the cases where this kind of information really is interesting
> seem to benefit a lot from having stack information available. That
> obviously has overhead, so we don't want the cost all the
> time. The script at
>
Jesse Zhang writes:
> On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
>> Is there any reason we don't just automatically run pgindent regularly?
>> Like once a week? And also update typedefs.list automatically, while
>> we're at it?
> You know what's better than weekly? Every check-in.
I'm
On Thu, Aug 13, 2020 at 10:21 AM Tom Lane wrote:
> Thomas Munro writes:
> > @@ -5911,11 +5912,11 @@ bgworker_should_start_now(BgWorkerStartTime
> > start_time)
> > + case PM_WAIT_READONLY:
> > + case PM_WAIT_CLIENTS:
> > case PM_RUN:
>
> So the
Hi,
On 2020-08-12 16:08:50 -0700, Jesse Zhang wrote:
> On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
> >
> > Hi,
> >
> > When developing patches I find it fairly painful that I cannot re-indent
> > patches with pgindent without also seeing a lot of indentation changes
> > in unmodified
Andres Freund writes:
> Given that pg_dump already re-orders the columns for DDL, could we make
> it apply that re-ordering not just during the CREATE TABLE, but also
> when dumping the table contents?
Hm, possibly. I think when this was last looked at, we didn't have any
way to get COPY to
Hi Andres,
On Wed, Aug 12, 2020 at 3:34 PM Andres Freund wrote:
>
> Hi,
>
> When developing patches I find it fairly painful that I cannot re-indent
> patches with pgindent without also seeing a lot of indentation changes
> in unmodified parts of files. It is easy enough ([1]) to only re-indent
On 2020-Aug-12, Andres Freund wrote:
> Is there any reason we don't just automatically run pgindent regularly?
> Like once a week? And also update typedefs.list automatically, while
> we're at it?
Seconded.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development,
On 2020-Jul-15, Tom Lane wrote:
> Issue #2: parallel restore does not work
>
> 1. dropdb r2; createdb r2
> 2. pg_restore -j8 -d r2 regression.dump
>
> This is fairly timing-dependent, but some attempts fail with messages
> like
>
> pg_restore: while PROCESSING TOC:
> pg_restore: from TOC
Hi,
On 2020-08-12 18:29:16 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I've attached the diff between first.sql and second.sql. Here's the
> > highlights:
>
> As I recall, the differences in b_star etc are expected, because
> pg_dump reorders that table's columns to match its inheritance
Hi,
When developing patches I find it fairly painful that I cannot re-indent
patches with pgindent without also seeing a lot of indentation changes
in unmodified parts of files. It is easy enough ([1]) to only re-indent
files that I have modified, but there's often a lot of independent
Andres Freund writes:
> I've attached the diff between first.sql and second.sql. Here's the
> highlights:
As I recall, the differences in b_star etc are expected, because
pg_dump reorders that table's columns to match its inheritance parent,
which they don't to start with because of ALTER TABLE
Thomas Munro writes:
> I think we also need:
> + else if (Shutdown <= SmartShutdown &&
> +backend_type == BACKEND_TYPE_AUTOVAC)
> + result = CAC_OK;
Hm, ok.
> Retesting the original complaint, I think we need:
> @@ -5911,11
Hi,
On 2020-07-15 15:52:03 -0400, Tom Lane wrote:
> I've been experimenting with trying to dump-and-restore the
> regression database, which is a test case that for some reason
> we don't cover in the buildfarm (pg_upgrade is not the same thing).
Yea, we really should have that. IIRC I was
On 2020-Jul-15, Tom Lane wrote:
> Issue #1: "--clean" does not work
>
> 1. createdb r2
> 2. pg_restore -d r2 regression.dump
> 3. pg_restore --clean -d r2 regression.dump
>
> pg_restore: while PROCESSING TOC:
> pg_restore: from TOC entry 6606; 1259 35458 INDEX idxpart32_a_idx postgres
>
On Thu, Aug 13, 2020 at 8:59 AM Tom Lane wrote:
> I wrote:
> > Oh, excellent point! I'd not thought to look at tests of the Shutdown
> > variable, but yeah, those should be <= SmartShutdown if we want autovac
> > to continue to operate in this state.
>
> On looking closer, there's another
I wrote:
> Oh, excellent point! I'd not thought to look at tests of the Shutdown
> variable, but yeah, those should be <= SmartShutdown if we want autovac
> to continue to operate in this state.
On looking closer, there's another problem: setting start_autovac_launcher
isn't enough to get the AV
On 2020-Aug-12, Alvaro Herrera wrote:
> 'anyvisible' mode is not required AFAICS; reading the code, I think this
> could also hit REINDEX CONCURRENTLY and CREATE INDEX CONCURRENTLY, which
> do not use that flag. I didn't try to reproduce it there, though.
> Anyway, I'm going to remove that
On Wed, Aug 12, 2020 at 4:25 AM Peter Eisentraut
wrote:
> Here is a patch to have pg_dump use pg_get_functiondef() instead of
> assembling the CREATE FUNCTION/PROCEDURE commands itself. This should
> save on maintenance effort in the future. It's also a prerequisite for
> being able to dump
Thomas Munro writes:
> On Thu, Aug 13, 2020 at 6:00 AM Tom Lane wrote:
>> One other thing I changed here was to remove PM_WAIT_READONLY from the
>> set of states in which we'll allow promotion to occur or a new walreceiver
>> to start. I'm not convinced that either of those behaviors aren't
>>
On Thu, Aug 13, 2020 at 6:00 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Thu, Aug 13, 2020 at 3:32 AM Bharath Rupireddy
> > wrote:
> >> After a smart shutdown is issued(with pg_ctl), run a parallel query,
> >> then the query hangs.
>
> > Yeah, the current situation is not good. I think
I am finally trying to move from python2.7 to python 3.x
for both 3.7 and 3.8 I have (attached log):
2020-08-12 18:35:47.433 CEST [10418] pg_regress/python3/ltree_plpython
ERROR: incompatible library "/pub/devel/postgresql/prov
On 2020-Aug-11, Alvaro Herrera wrote:
> A much more troubling thought is what happens if the range is
> desummarized, then the index item is used for the summary of a different
> range. Then the index might end up returning corrupt results.
Actually, this is not a concern because the brin
Thomas Munro writes:
> On Thu, Aug 13, 2020 at 3:32 AM Bharath Rupireddy
> wrote:
>> After a smart shutdown is issued(with pg_ctl), run a parallel query,
>> then the query hangs.
> Yeah, the current situation is not good. I think your option 2 sounds
> better, because the documented behaviour
On Tue, 11 Aug 2020 at 13:45, Thomas Kellerer wrote:
>
> Jaime Casanova schrieb am 11.08.2020 um 20:39:
> >> As a follow-up to bug #16570 [1] and other previous discussions
> >> on the mailing-lists, I'm checking out PG13 beta for Windows
> >> from:
> >>
On Thu, Aug 13, 2020 at 3:32 AM Bharath Rupireddy
wrote:
> After a smart shutdown is issued(with pg_ctl), run a parallel query,
> then the query hangs. The postmaster doesn't inform backends about the
> smart shutdown(see pmdie() -> SIGTERM -> BACKEND_TYPE_NORMAL are not
> informed), so if they
Hi
I would like to start another thread to follow up on [1], mostly to bump up the
topic. Just to remind, it's about how pg_stat_statements jumbling ArrayExpr in
queries like:
SELECT something FROM table WHERE col IN (1, 2, 3, ...)
The current implementation produces different jumble hash
On 2020-Aug-11, Alvaro Herrera wrote:
> I think this is more complicated than necessary. It seems easier to
> solve this problem by just checking whether the given root pointer is
> set to InvalidOffsetNumber, which is already done in the existing coding
> of heap_get_root_tuples (only they
On 2020-Jul-28, Peter Geoghegan wrote:
> On Mon, Jul 27, 2020 at 10:25 AM Alvaro Herrera
> wrote:
> > (I was also considering whether it needs to be a loop to reobtain root
> > tuples, in case a concurrent transaction can create a new item while
> > we're checking that item; but I don't think
Hi,
After a smart shutdown is issued(with pg_ctl), run a parallel query,
then the query hangs. The postmaster doesn't inform backends about the
smart shutdown(see pmdie() -> SIGTERM -> BACKEND_TYPE_NORMAL are not
informed), so if they request parallel workers, the postmaster is
unable to fork
On Wed, Aug 12, 2020 at 12:28:20AM -0500, Justin Pryzby wrote:
> On Wed, Aug 12, 2020 at 01:54:38PM +0900, Michael Paquier wrote:
>> +++ b/src/backend/catalog/index.c
>> @@ -3661,20 +3662,12 @@ reindex_relation(Oid relid, int flags, int options)
>> +elog(ERROR, "unsupported relation
Thanks Robert for the review. Please find my comments inline below:
On Fri, Aug 7, 2020 at 9:21 PM Robert Haas wrote:
>
> On Thu, Aug 6, 2020 at 9:23 AM Ashutosh Sharma wrote:
> > Attached v4 patch fixes the latest comments from Robert and Masahiko-san.
>
> Compiler warning:
>
>
On Wed, Aug 12, 2020 at 8:21 PM Dave Cramer
wrote:
>
>
> On Wed, 12 Aug 2020 at 08:14, Andy Fan wrote:
>
>>
>>
>> On Wed, Aug 12, 2020 at 8:11 PM Andy Fan
>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 12, 2020 at 5:54 PM Dave Cramer
>>> wrote:
>>>
On Tue, 11 Aug 2020 at 22:33, Andy
On Wed, 12 Aug 2020 at 08:14, Andy Fan wrote:
>
>
> On Wed, Aug 12, 2020 at 8:11 PM Andy Fan wrote:
>
>>
>>
>> On Wed, Aug 12, 2020 at 5:54 PM Dave Cramer
>> wrote:
>>
>>>
>>>
>>>
>>> On Tue, 11 Aug 2020 at 22:33, Andy Fan wrote:
>>>
On Mon, Jul 27, 2020 at 11:57 AM Andy Fan
On Wed, Aug 12, 2020 at 8:11 PM Andy Fan wrote:
>
>
> On Wed, Aug 12, 2020 at 5:54 PM Dave Cramer
> wrote:
>
>>
>>
>>
>> On Tue, 11 Aug 2020 at 22:33, Andy Fan wrote:
>>
>>>
>>>
>>> On Mon, Jul 27, 2020 at 11:57 AM Andy Fan
>>> wrote:
>>>
> 2. Currently I want to add a new GUC
On Wed, Aug 12, 2020 at 5:54 PM Dave Cramer
wrote:
>
>
>
> On Tue, 11 Aug 2020 at 22:33, Andy Fan wrote:
>
>>
>>
>> On Mon, Jul 27, 2020 at 11:57 AM Andy Fan
>> wrote:
>>
>>>
2. Currently I want to add a new GUC parameter, if set it to true,
server will
create a holdable portal,
Re: Tom Lane
> > (The Debian regression tests remove plpgsql before testing all
> > extensions in turn.)
>
> Meh. I think that's testing a case that we don't guarantee to work.
> There was already a plpgsql dependency in hstore--1.1--1.2.sql,
> which I just cribbed from to make these fixes.
The
On Tue, 11 Aug 2020 at 22:33, Andy Fan wrote:
>
>
> On Mon, Jul 27, 2020 at 11:57 AM Andy Fan
> wrote:
>
>>
>>> 2. Currently I want to add a new GUC parameter, if set it to true,
>>> server will
>>> create a holdable portal, or else nothing changed. Then let the user
>>> set
>>> it to true in
Here is a patch to have pg_dump use pg_get_functiondef() instead of
assembling the CREATE FUNCTION/PROCEDURE commands itself. This should
save on maintenance effort in the future. It's also a prerequisite for
being able to dump functions with SQL-standard function body discussed
in [0].
On 12.08.2020 09:12, Peter Eisentraut wrote:
There are two ancient hacks in the cygwin and solaris ports that appear
to have been solved more than 10 years ago, so I think we can remove
them. See attached patches.
Hi Peter,
This is really archeology
Check for b20.1
as it was released
There are two ancient hacks in the cygwin and solaris ports that appear
to have been solved more than 10 years ago, so I think we can remove
them. See attached patches.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
On Wed, 12 Aug 2020 at 14:06, Asim Praveen wrote:
>
>
>
> > On 11-Aug-2020, at 8:57 PM, Robert Haas wrote:
> >
> > I think this gets to the root of the issue. If we check the flag
> > without a lock, we might see a slightly stale value. But, considering
> > that there's no particular amount of
On Sat, Aug 8, 2020 at 2:44 AM Robert Haas wrote:
> On Wed, Aug 5, 2020 at 2:01 AM Thomas Munro wrote:
> > * Master is around 11% faster than last week before commit c5315f4f
> > "Cache smgrnblocks() results in recovery."
> > * This patch gives a similar speedup, bringing the total to around 25%
69 matches
Mail list logo
