On Tue, Aug 09, 2022 at 10:35:01AM -0400, Tom Lane wrote:
> Agreed this is a bug, but I do not think we should add the proposed
> regression test, regardless of where exactly. It looks like expending
> a lot of cycles forevermore to watch for an extremely unlikely thing,
> ie that we break this
On Tue, Aug 16, 2022 at 11:28 PM Robert Haas wrote:
>
> It claims that:
>
> * 'RecPtr' should point to the beginning of a valid WAL record. Pointing at
> * the beginning of a page is also OK, if there is a new record right after
> * the page header, i.e. not a continuation.
>
> But this
On Wed, Aug 17, 2022 at 2:52 AM Nathan Bossart wrote:
>
> On Tue, Jul 19, 2022 at 05:29:10PM +0530, Bharath Rupireddy wrote:
> > I've also added the total number of WAL files a checkpoint has
> > processed (scanned the pg_wal directory) while removing old WAL files.
> > This helps to estimate the
Hello,
I've a slightly modified version of test_shm_mq, that I changed to include
a shared fileset. The motivation to do that came because I hit an
assertion failure with PG15 while doing some development work on BDR and I
suspected it to be a PG15 bug.
The stack trace looks as below:
(lldb)
dummyret hasn't been used in a while (last use removed by 50d22de932,
and before that 84b6d5f359), and since we are now preferring inline
functions over complex macros, it's unlikely to be needed again.From 513c41d4a79cad768d5ead3366a43def2b3e272b Mon Sep 17 00:00:00 2001
From: Peter
On Wed, Aug 17, 2022 at 6:27 AM Andres Freund wrote:
>
> Hi,
>
> On 2022-08-16 19:55:18 -0400, Tom Lane wrote:
> > Robert Haas writes:
> > > What sort of random things would someone do with pageinspect functions
> > > that would hold buffer pins on one buffer while locking another one?
> > > The
On Tue, Aug 16, 2022 at 10:04 PM Robert Haas wrote:
>
> Hi,
>
> I was looking at the code for pg_walinspect today and I think I may
> have found a bug (or else I'm confused about how this all works, which
> is also possible). ReadNextXLogRecord() takes an argument first_record
> of type
On Fri, Aug 12, 2022 at 6:33 PM Robert Haas wrote:
>
> On Thu, Aug 11, 2022 at 2:15 PM Robert Haas wrote:
> > As far as I know, this 0001 addresses all outstanding comments and
> > fixes the reported bug.
> >
> > Does anyone think otherwise?
>
> If they do, they're keeping quiet, so I committed
Hi,
My name is Aravind and I am part of IBM CICS TX product development and
support. We have a requirement from one of our customers to use IBM CICS TX
with Postgresql 13/14. IBM CICS TX is a Transaction Manager middleware product
that is deployed as container on Kubernetes platforms. IBM
Hi,
My name is Aravind and I am part of IBM CICS TX product development and
support. We have a requirement from one of our customers to use IBM CICS TX
with Postgresql 13/14. IBM CICS TX is a Transaction Manager middleware product
that is deployed as container on Kubernetes platforms. IBM
On Tuesday, August 2, 2022 8:00 PM Amit Kapila wrote:
> On Tue, Jul 26, 2022 at 9:07 AM Amit Kapila wrote:
> >
> > On Tue, Jul 26, 2022 at 7:13 AM Jonathan S. Katz
> wrote:
> > >
> > > Thanks for the example. I agree that it is fairly simple to reproduce.
> > >
> > > I understand that
On Wed, Aug 17, 2022 at 8:14 AM Andres Freund wrote:
> > > > +/* functions shared between guc.c and guc-file.l */
> > > > [...]
> > > I think I prefer your suggestion of a guc_internal.h upthread.
> >
> > Started in 0002, but left open the headerscheck failure.
> >
> > Also, if such a thing is
Quan Zongliang writes:
> 1. When using extended PGroonga
> ...
> 3. Neither ID = 'f' nor id= 't' can use the index correctly.
This works fine for btree indexes. I think the actual problem
is that IsBooleanOpfamily only accepts the btree and hash
opclasses, and that's what needs to be improved.
On Tue, Aug 02, 2022 at 11:21:04PM +1200, David Rowley wrote:
> I've now pushed the patch.
I've not studied the patch at all.
But in a few places, it removes the locally-computed group_pathkeys:
- List *group_pathkeys = root->group_pathkeys;
However it doesn't do
On Sun, Nov 14, 2021 at 10:33:19AM +0800, Japin Li wrote:
>
> On Sat, 13 Nov 2021 at 23:42, Tom Lane wrote:
> > Japin Li writes:
> >> postgres=# CREATE TABLE tbl (s varchar(2147483647));
> >> ERROR: length for type varchar cannot exceed 10485760
> >> LINE 1: CREATE TABLE tbl (s
Andres Freund writes:
> On 2022-08-16 17:41:43 +0700, John Naylor wrote:
>> That directive has been supported in Bison since 2.4.2.
> 2.4.2 is from 2010. So I think we could just start relying on it?
Apple is still shipping 2.3. Is this worth enough to make Mac
users install a non-default
Hi,
On 8/15/22 10:14 PM, Andres Freund wrote:
I pushed a few cleanups to https://github.com/anarazel/postgres/commits/json
while I was hacking on this (ignore that it's based on the meson tree, that's
just faster for me). Some of them might not be applicable anymore, but it
might still make
Hi,
1. When using extended PGroonga
CREATE EXTENSION pgroonga;
CREATE TABLE memos (
id boolean,
content varchar
);
CREATE INDEX idxA ON memos USING pgroonga (id);
2. Disable bitmapscan and seqscan:
SET enable_seqscan=off;
SET enable_indexscan=on;
SET enable_bitmapscan=off;
3. Neither
Hi,
On 2022-08-16 17:41:43 +0700, John Naylor wrote:
> For v3, I addressed some comments and added .h files to the
> headerscheck exceptions.
Thanks!
> /*
> * NB: include bootparse.h only AFTER including bootstrap.h, because
> bootstrap.h
> * includes node definitions needed for YYSTYPE.
>
On Wed, Aug 17, 2022 at 6:34 AM Daniel Gustafsson wrote:
>
> > On 16 Aug 2022, at 16:03, Tom Lane wrote:
>
> > I agree though that while simplifying list_length() calls, I'd lean to using
> > explicit comparisons to NIL.
>
>
> Agreed, I prefer that too.
>
Thanks for the feedback.
PSA patch v3
Hi,
On 2022-08-16 19:55:18 -0400, Tom Lane wrote:
> Robert Haas writes:
> > What sort of random things would someone do with pageinspect functions
> > that would hold buffer pins on one buffer while locking another one?
> > The functions in hashfuncs.c don't even seem like they would access
> >
Hi,
On 2022-08-16 17:02:27 -0400, Tom Lane wrote:
> Robert Haas writes:
> > I had that thought too, but I don't *think* it's the case. This
> > function acquires a lock on the oldest bucket page, then on the new
> > bucket page. We could deadlock if someone who holds a pin on the new
> > bucket
Robert Haas writes:
> What sort of random things would someone do with pageinspect functions
> that would hold buffer pins on one buffer while locking another one?
> The functions in hashfuncs.c don't even seem like they would access
> multiple buffers in total, let alone at overlapping times.
On Tue, Aug 16, 2022 at 5:02 PM Tom Lane wrote:
> Robert Haas writes:
> > I had that thought too, but I don't *think* it's the case. This
> > function acquires a lock on the oldest bucket page, then on the new
> > bucket page. We could deadlock if someone who holds a pin on the new
> > bucket
On Mon, Aug 15, 2022 at 02:47:25PM -0700, Jeremy Schneider wrote:
> I'll take a look at the patch if I can... and I'm hopeful that we're
> able to move this idea forward and get this little gap in PG filled once
> and for all!
Thanks!
I noticed that the "result" variable in
On Tue, Jul 19, 2022 at 05:29:10PM +0530, Bharath Rupireddy wrote:
> I've also added the total number of WAL files a checkpoint has
> processed (scanned the pg_wal directory) while removing old WAL files.
> This helps to estimate the pg_wal disk space at the time of a
> particular checkpoint,
On Wed, Aug 10, 2022 at 11:00:20AM -0400, Robert Haas wrote:
> Maybe the checkpointer is a better candidate, but somehow I feel that
> we can't consider this sort of thing separate from the existing
> progress reporting that checkpointer already does. Perhaps we need to
> think of changing or
Robert Haas writes:
> I had that thought too, but I don't *think* it's the case. This
> function acquires a lock on the oldest bucket page, then on the new
> bucket page. We could deadlock if someone who holds a pin on the new
> bucket page tries to take a content lock on the old bucket page. But
I wrote:
> ... We can fix
> that by adding an index array to go straight from phid to the
> PlaceHolderInfo. While thinking about where to construct such
> an index array, I decided it'd be a good idea to have an explicit
> step to "freeze" the set of PlaceHolderInfos, at the start of
>
On Wed, Aug 10, 2022 at 1:28 AM Andres Freund wrote:
> I assume this is trying to defend against some sort of deadlock by not
> actually getting a cleanup lock (by passing get_cleanup_lock = true to
> XLogReadBufferForRedoExtended()).
I had that thought too, but I don't *think* it's the case.
> On 16 Aug 2022, at 16:03, Tom Lane wrote:
> I agree though that while simplifying list_length() calls, I'd lean to using
> explicit comparisons to NIL.
Agreed, I prefer that too.
--
Daniel Gustafsson https://vmware.com/
On Wed, Aug 10, 2022 at 03:28:25PM +0530, Bharath Rupireddy wrote:
> snprintf(path, sizeof(path), "pg_logical/mappings/%s",
> mapping_de->d_name);
> - if (lstat(path, ) == 0 && !S_ISREG(statbuf.st_mode))
> + if (get_dirent_type(path, mapping_de, false, LOG)
On 2022-08-16 Tu 14:12, Israel Barth Rubio wrote:
> Hello all,
>
> With the current implementation of COPY FROM in PostgreSQL we are able to
> load the DEFAULT value/expression of a column if the column is absent
> in the
> list of specified columns. We are not able to explicitly ask that
>
On Sat, Jul 16, 2022 at 5:18 PM Thomas Munro wrote:
> On Sat, Jul 16, 2022 at 1:28 AM Tom Lane wrote:
> > Thomas Munro writes:
> > > On Fri, Jul 15, 2022 at 9:34 AM Tom Lane wrote:
> > >> (Someday we oughta go ahead and make our Windows signal API look more
> > >> like POSIX, as I suggested
Andrey Borodin wrote 2022-07-23 11:39:
Yura, thank you for your benchmarks!
We already knew that patch can save the day on pathological workloads,
now we have a proof of this.
Also there's the evidence that user can blindly increase size of SLRU
if they want (with the second patch). So there's
Hello all,
With the current implementation of COPY FROM in PostgreSQL we are able to
load the DEFAULT value/expression of a column if the column is absent in the
list of specified columns. We are not able to explicitly ask that
PostgreSQL uses
the DEFAULT value/expression in a column that is
I wrote:
> Richard Guo writes:
>> If the two issues are indeed something we need to fix, maybe we can
>> change add_placeholders_to_joinrel() to search the PHVs from
>> outer_rel/inner_rel's targetlist, and add the ojrelid to phnullingrels
>> if needed, just like what we do in
Forgot the attachment.
waldump-beginread.patch
Description: Binary data
It claims that:
* 'RecPtr' should point to the beginning of a valid WAL record. Pointing at
* the beginning of a page is also OK, if there is a new record right after
* the page header, i.e. not a continuation.
But this actually doesn't seem to work. This function doesn't itself
have any
On Mon, Aug 8, 2022 at 2:08 PM Peter Smith wrote:
>
> PSA patch version v1* for a new "Column Lists" pgdocs section
>
> This is just a first draft, but I wanted to post it as-is, with the
> hope that I can get some feedback while continuing to work on it.
Few comments:
1) Row filters mentions
On Tue, Aug 16, 2022 at 2:02 AM Drouvot, Bertrand wrote:
> On 8/14/22 11:57 AM, Michael Paquier wrote:
> >One thing was itching me about the serialization and
> > deserialization logic though: could it be more readable if we used an
> > intermediate structure to store the length of the
On Fri, Aug 12, 2022 at 6:32 AM Drouvot, Bertrand wrote:
> It has been agreed that the work on this patch is on hold until the
> ClientConnectionInfo related work is finished (see the discussion in [1]).
>
> Having said that I'm attaching a new patch
> "v2-0004-system_user-implementation.patch"
On 2022-Aug-16, Andrew Dunstan wrote:
> I don't think there's a hard and fast rule about it. Certainly the case
> would be more compelling if the functions were used across different TAP
> suites. The SSL suite has suite-specific modules. That's a pattern also
> worth considering. e.g something
Hi,
I was looking at the code for pg_walinspect today and I think I may
have found a bug (or else I'm confused about how this all works, which
is also possible). ReadNextXLogRecord() takes an argument first_record
of type XLogRecPtr which is used only for error reporting purposes: if
we fail to
On Tue, Aug 16, 2022 at 7:26 PM Christoph Berg wrote:
>
> Re: Bharath Rupireddy
> > Don't we need a similar explanation [1] for pg_recvlogical docs?
> >
> > [1]
> >
> > In the absence of fatal errors, pg_receivewal
> > - will run until terminated by the SIGINT signal
> > - ( >
On 2022-08-15 Mo 22:25, Bharath Rupireddy wrote:
> Hi,
>
> It seems like find_in_log() and advance_wal() functions (which are now
> being used in at least 2 places). find_in_log() is defined and being
> used in 2 places 019_replslot_limit.pl and 033_replay_tsp_drops.pl.
> The functionality of
Hello,
On Fri, Aug 12, 2022 at 6:34 AM Drouvot, Bertrand wrote:
> +typedef struct
> +{
> + /*
> +* Authenticated identity. The meaning of this identifier is
> dependent on
>
> has to be replaced by:
>
> +typedef struct ClientConnectionInfo
> +{
> + /*
> +*
Richard Guo writes:
> When we add required PlaceHolderVars to a join rel's targetlist, if the
> PHV can be computed in the nullable-side of the join, we would add the
> join's RT index to phnullingrels. This is correct as we know the PHV's
> value can be nulled at this join. But I'm wondering if
Hi,
On 2022-08-16 11:33:12 -0400, Andrew Dunstan wrote:
> On 2022-08-15 Mo 23:20, Andres Freund wrote:
> >
> > I've also attached a 0003 that splits the log location from the data
> > location. That could be used to make the log file location symmetrical
> > between
> > pg_regress (log/) and tap
On Mon, Aug 15, 2022 at 10:09:29PM +0530, vignesh C wrote:
> I have updated the patch to display "Objects depending on extension"
> as describe extension footer. The changes for the same are available
> in the v2 version patch attached. Thoughts?
I wonder if we would be better off with a
On 2022-08-15 Mo 23:20, Andres Freund wrote:
>
> I've also attached a 0003 that splits the log location from the data
> location. That could be used to make the log file location symmetrical between
> pg_regress (log/) and tap tests (tmp_check/log). But it'd break the
> buildfarm's tap test log
Andres Freund writes:
> On 2022-08-11 11:26:39 -0400, Tom Lane wrote:
>> Given that it's no longer going to be the same tmp_check dir used
>> elsewhere, maybe we could s/tmp_check/tab_comp_dir/g or something
>> like that? That'd add some clarity I think.
> Done in the attached patch (0001).
I
On Tue, Aug 16, 2022 at 3:16 AM Bharath Rupireddy
wrote:
>
> On Tue, Aug 16, 2022 at 1:55 PM Drouvot, Bertrand wrote:
> >
> > Hi,
> >
> > On 8/16/22 10:10 AM, Bharath Rupireddy wrote:
> > > On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand
> > > wrote:
> > >> On 8/14/22 7:52 AM, Gurjeet Singh
Robert Haas writes:
> On Mon, Aug 15, 2022 at 9:28 PM Tom Lane wrote:
>> That's because the *correct* way to write it is either "alist == NIL"
>> or just "!alist".
> I think the alist == NIL (or alist != NIL) style often makes the code
> easier to read. I recommend we standardize on that one.
Re: Bharath Rupireddy
> Don't we need a similar explanation [1] for pg_recvlogical docs?
>
> [1]
>
> In the absence of fatal errors, pg_receivewal
> - will run until terminated by the SIGINT signal
> - ( action="simul">ControlC).
> + will run until terminated by the SIGINT
> + (
On Mon, Aug 15, 2022 at 6:39 PM Andres Freund wrote:
> I don't think it's sane from a performance view to start a subtransaction for
> every coercion, particularly because most coercion paths will never trigger an
> error, leaving things like out-of-memory or interrupts aside. And those are
>
Peter Eisentraut writes:
> Looking to tidy up c.h a bit, I think the NON_EXEC_STATIC #define
> doesn't need to be known globally, and it's not related to establishing
> a portable C environment, so I propose to move it to a more localized
> header, such as postmaster.h, as in the attached
On Mon, Aug 15, 2022 at 9:28 PM Tom Lane wrote:
> Peter Smith writes:
> > During a recent code review I was going to suggest that some new code
> > would be more readable if the following:
> > if (list_length(alist) == 0) ...
>
> > was replaced with:
> > if (list_is_empty(alist)) ...
>
> > but
Daniel Gustafsson writes:
> I think these are nice cleanups to simplify and streamline the code, just a
> few
> small comments from reading the patch:
> /* If no subcommands, don't collect */
> - if
> (list_length(currentEventTriggerState->currentCommand->d.alterTable.subcmds)
> !=
On Tue, Aug 16, 2022 at 5:15 PM Daniel Gustafsson wrote:
>
> > On 16 Aug 2022, at 13:36, Christoph Berg wrote:
>
> >> pqsignal(SIGINT, sigint_handler);
> >> +pqsignal(SIGTERM, sigint_handler);
> >> Tiny nitpick, I think we should rename sigint_handler to just sig_handler
> >> as it
>
On Tue, Aug 16, 2022 at 11:35 AM Zheng Li wrote:
>
> > Can we think of relying to send WAL of such DDLs just based on whether
> > there is a corresponding publication (ex. publication of ALL OBJECTS)?
> > I mean avoid database-specific filtering in decoding for such DDL
> > commands but not sure
> On 16 Aug 2022, at 13:36, Christoph Berg wrote:
>> pqsignal(SIGINT, sigint_handler);
>> +pqsignal(SIGTERM, sigint_handler);
>> Tiny nitpick, I think we should rename sigint_handler to just sig_handler as
>> it
>> does handle more than sigint.
>
> I went with sigexit_handler since
Re: Daniel Gustafsson
> In general that's a good idea, but they are so trivial that I don't really see
> much point in doing that in this particular case.
Plus the variable they set is called differently...
Christoph
> On 16 Aug 2022, at 13:40, Bharath Rupireddy
> wrote:
>
> On Tue, Aug 16, 2022 at 5:06 PM Christoph Berg wrote:
>> I went with sigexit_handler since pg_recvlogical has also a
>> sighup_handler and "sig_handler" would be confusing there.
>
> Can we move these signal handlers to
On Tue, Aug 16, 2022 at 5:06 PM Christoph Berg wrote:
>
> Re: Daniel Gustafsson
> > Do you think pg_recvlogical should support SIGTERM as well? (The signals
> > which
> > it does trap should be added to the documentation which just now says "until
> > terminated by a signal" but that's a
Re: Daniel Gustafsson
> Do you think pg_recvlogical should support SIGTERM as well? (The signals
> which
> it does trap should be added to the documentation which just now says "until
> terminated by a signal" but that's a separate thing.)
Ack, that makes sense, added in the attached updated
Looking to tidy up c.h a bit, I think the NON_EXEC_STATIC #define
doesn't need to be known globally, and it's not related to establishing
a portable C environment, so I propose to move it to a more localized
header, such as postmaster.h, as in the attached patch.From
For v3, I addressed some comments and added .h files to the
headerscheck exceptions.
On Tue, Aug 16, 2022 at 1:11 AM Andres Freund wrote:
> On 2022-08-13 15:39:06 +0700, John Naylor wrote:
> > Here are the rest. Most of it was pretty straightforward, with the
> > main exception of
> On 15 Aug 2022, at 14:45, Christoph Berg wrote:
> The problem was that systemd's default KillSignal is SIGTERM, while
> pg_receivewal flushes the output compression buffers on SIGINT only.
Supporting SIGTERM here makes sense, especially given how systemd works.
> The attached patch makes it
On Tue, Aug 16, 2022 at 1:55 PM Drouvot, Bertrand wrote:
>
> Hi,
>
> On 8/16/22 10:10 AM, Bharath Rupireddy wrote:
> > On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand
> > wrote:
> >> On 8/14/22 7:52 AM, Gurjeet Singh wrote:
> >>> On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand
> >>> wrote:
On Tue, Aug 16, 2022 at 2:32 PM Masahiko Sawada wrote:
>
> On Tue, Aug 16, 2022 at 2:31 PM Amit Kapila wrote:
> >
> > On Tue, Aug 16, 2022 at 10:56 AM Masahiko Sawada
> > wrote:
> > >
> > > On Tue, Aug 16, 2022 at 2:08 PM Amit Kapila
> > > wrote:
> > > >
> > > > On Tue, Aug 16, 2022 at 9:28
> On 16 Aug 2022, at 10:25, Masahiko Sawada wrote:
>
> The same issue is recently reported[1] on -bugs
Oh, I missed that thread.
> and I proposed the
> patch that adds CHECK_FOR_INTERRUPTS() to the loop in
> ReorderBufferProcessTXN().
I agree that it's a good place for check.
> I think it
> On 16 Aug 2022, at 07:27, Shinoda, Noriyoshi (PN Japan FSIP)
> wrote:
>
> Hello, hackers.
>
> As of PostgreSQL 14, "tty" in the libpq connection string has already been
> removed with the commit below.
>
> On 16 Aug 2022, at 07:29, Peter Smith wrote:
> On Tue, Aug 16, 2022 at 11:27 AM Tom Lane wrote:
>> if you want to get rid of overcomplicated uses of
>> list_length() in favor of one of those spellings, have at it.
>
> Done, and tested OK with make check-world.
I think these are nice
esOn Tue, 9 Aug 2022 at 19:10, David Rowley wrote:
> I've not had a chance to look at the 0003 patch yet.
I've looked at the 0003 patch now.
The performance numbers look quite impressive, however, there were a
few things about the patch that I struggled to figure what they were
done the way you
Hi,
On 8/16/22 10:10 AM, Bharath Rupireddy wrote:
On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand wrote:
On 8/14/22 7:52 AM, Gurjeet Singh wrote:
On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand wrote:
I think we can reduce the number of places the hook is called, if we
call the hook from
On Tue, Aug 16, 2022 at 1:31 PM Drouvot, Bertrand wrote:
>
> On 8/14/22 7:52 AM, Gurjeet Singh wrote:
> > On Mon, Aug 8, 2022 at 3:51 AM Drouvot, Bertrand
> > wrote:
>
> > I think we can reduce the number of places the hook is called, if we
> > call the hook from proc_exit(), and at all the
On Fri, August 12, 2022 17:22 PM Peter Smith wrote:
> Here are some review comments for v20-0004:
>
> (This completes my reviews of the v20* patch set. Sorry, the reviews
> are time consuming, so I am lagging slightly behind the latest posted
> version)
Thanks for your comments.
> 1.
Hi,
On Fri, Jul 29, 2022 at 08:36:44AM -0500, Daymel Bonne Solís wrote:
>
> We have rewritten the patch and added the necessary columns to have the
> number of times a parallel query plan was not executed using parallelism.
>
> We are investigating how to add more information related to the
Hi,
On Sat, Jul 30, 2022 at 04:09:36PM +0800, Julien Rouhaud wrote:
>
> - 0001: the rule_number / mapping_number addition in the views in a separate
> commit
> - 0002: the main file inclusion patch. Only a few minor bugfix since
> previous version discovered thanks to the tests (a bit more
> Can we think of relying to send WAL of such DDLs just based on whether
> there is a corresponding publication (ex. publication of ALL OBJECTS)?
> I mean avoid database-specific filtering in decoding for such DDL
> commands but not sure how much better it is than the current proposal?
I think a
81 matches
Mail list logo
