I suppose if it's correct that we need to lock the table first (at least
in ACCESS SHARE mode), an option to LOCK perhaps makes
more sense. Maybe you could specify two modes like:
LOCK TABLE IN _lockmode_ MODE AND THEN WAIT FOR CONFLICTS WITH _waitmode_ MODE;
But that might be excessive. :-D And
On Thu, Jan 12, 2023 at 12:44 PM Masahiko Sawada
wrote:
>
> On Wed, Jan 11, 2023 at 12:13 PM John Naylor
> wrote:
> >
> > On Tue, Jan 10, 2023 at 7:08 PM Masahiko Sawada
wrote:
> I agree to keep this as a template.
Okay, I'll squash the previous patch and work on cleaning up the internals.
I'l
Hi,
Thanks for your reviews.
Takamichi Osumi (Fujitsu) , 12 Oca 2023 Per,
06:07 tarihinde şunu yazdı:
> On Wednesday, January 11, 2023 7:45 PM Melih Mutlu
> wrote:
> (1-1) There is no need to log the version and the query by elog here.
> (1-2) Also, I suggest we can remove the server_version va
At Mon, 9 Jan 2023 20:00:00 +0530, Bharath Rupireddy
wrote in
> I propose to statically allocate these two pages using PGAlignedBlock
> structure lazily in verifyBackupPageConsistency() to not waste dynamic
> memory worth 2*BLCKSZ bytes. I'm attaching a small patch herewith.
>
> Thoughts?
IMHO
On Thu, Jan 12, 2023 at 4:29 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 9 Jan 2023 20:00:00 +0530, Bharath Rupireddy
> wrote in
> > I propose to statically allocate these two pages using PGAlignedBlock
> > structure lazily in verifyBackupPageConsistency() to not waste dynamic
> > memory worth 2*BLC
On Wed, Jan 11, 2023 at 5:33 PM Andres Freund wrote:
> Hi,
>
> On 2023-01-11 10:29:06 +0100, Anthonin Bonnefoy wrote:
> > Currently, the Checkpointer process only reports SLRU statistics at
> server
> > shutdown, leading to delayed statistics for SLRU flushes. This patch
> adds a
> > flush of SLR
On Thu, Jan 12, 2023 at 2:50 PM Zhang Mingli wrote:
> On Jan 12, 2023, 14:34 +0800, Zhang Mingli , wrote:
>
> Some conditions in shm_toc_insert and shm_toc_allocate are bogus, like:
> if (toc_bytes + nbytes > total_bytes || toc_bytes + nbytes < toc_bytes)
> Remove the condition `toc_bytes + nbyte
> Simpler is better when it comes to authentication
I definitely agree with that, and if we didn't have existing
parsing logic for pg_hba.conf I would agree. But given the existing
logic for pg_hba.conf, I think the path of least surprises is to
support all of the same patterns that pg_hbac.conf s
On 10.01.23 07:20, Amit Kapila wrote:
The existing uses of %m are wrong. This was already fixed once in
7897e3bb902c557412645b82120f4d95f7474906, but the affected areas of code
were apparently developed at around the same time and didn't get the
fix. So I have attached a separate patch to fix t
Hi,
I'm migrating our existing PG instances from PG11.4 to PG14.3. I
have around 5 Million Tables in a single database. When migrating using
pg_upgrade, its taking 3 hours for the process to complete. I'm not sure if
its the intended behaviour or we're missing something here.
Most of
Technically correct name of this feature would be Readable Names for
Operators, or Pronounceable Names for Operators. But I'd like to call
it Named Operators.
With this patch in place, the users can name the operators as
:some_pronounceable_name: instead of having to choose from the special
charac
Please see attached a slightly updated patch. There were some comment
changes sitting in uncommitted in Git worktree, that were missed.
Best regards,
Gurjeet
http://Gurje.et
named_operators_v1.patch
Description: Binary data
On Thu, Jan 12, 2023 at 1:59 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 9 Jan 2023 20:00:00 +0530, Bharath Rupireddy
> wrote in
> > I propose to statically allocate these two pages using PGAlignedBlock
> > structure lazily in verifyBackupPageConsistency() to not waste dynamic
> > memory worth 2*BLC
Hi hackers,
Please find attached a patch to $SUBJECT.
It is a preliminary patch for [1].
The main ideas are: 1) to have consistent naming between the pg_stat_get*()
functions
and their associated counters and 2) to define the new macros in [1] the same
way as it
has been done in 8018ffbf58 (a
On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
>
> Technically correct name of this feature would be Readable Names for
> Operators, or Pronounceable Names for Operators. But I'd like to call
> it Named Operators.
>
> With this patch in place, the users can name the operators as
> :some_pronou
On Wed, Jan 11, 2023 at 6:16 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > 2.
> > I think users can set ' wal_receiver_status_interval ' to 0 or more
> > than 'wal_sender_timeout'. But is this a frequent use-case scenario or
> > do we see DBAs setting these in such a way by mistake? If so, then I
> > th
Dear all,
I think I've found a problem in logical replication that was introduced
recently in the patch:
Fix calculation of which GENERATED columns need to be updated
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=3f7836ff651ad710fef52fa87b248ecdfc6468dc
There is an assertion
On Thu, Jan 12, 2023 at 10:34 AM Amit Kapila wrote:
>
> On Thu, Jan 12, 2023 at 9:54 AM Peter Smith wrote:
> >
> >
> > doc/src/sgml/monitoring.sgml
> >
> > 5. pg_stat_subscription
> >
> > @@ -3198,11 +3198,22 @@ SELECT pid, wait_event_type, wait_event FROM
> > pg_stat_activity WHERE wait_event i
On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
wrote:
>
> On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
> >
> > Technically correct name of this feature would be Readable Names for
> > Operators, or Pronounceable Names for Operators. But I'd like to call
> > it Named Operators.
> >
>
On Thu, Jan 12, 2023 at 02:45:41PM +0530, Vigneshk Kvignesh wrote:
>Hi,
>
> I'm migrating our existing PG instances from PG11.4 to PG14.3. I
>have around 5 Million Tables in a single database. When migrating using
>pg_upgrade, its taking 3 hours for the process to comple
On Thu, Jan 12, 2023 at 4:21 PM shveta malik wrote:
>
> On Thu, Jan 12, 2023 at 10:34 AM Amit Kapila wrote:
> >
> > On Thu, Jan 12, 2023 at 9:54 AM Peter Smith wrote:
> > >
> > >
> > > doc/src/sgml/monitoring.sgml
> > >
> > > 5. pg_stat_subscription
> > >
> > > @@ -3198,11 +3198,22 @@ SELECT pid
Hi,
As discussed [1], here's a patch to beautify pg_walinspect docs
similar to pageinspect docs. The existing pg_walinspect docs calls out
the column names explicitly and then also shows them in the function
execution examples which is duplicate and too informative. Also \x
isn't used so some of t
On Thu, Jan 12, 2023 at 11:23 AM Michael Paquier wrote:
>
> On Wed, Jan 11, 2023 at 06:59:18PM +0530, Bharath Rupireddy wrote:
> > I've done it that way for pg_get_wal_fpi_info. If this format looks
> > okay, I can propose to do the same for other functions (for
> > backpatching too) in a separate
Tom Lane wrote:
> I agree that it seems like a good idea to try.
> There will be more per-row overhead, but the increase in flexibility
> is likely to justify that.
Here's a POC patch implementing row-by-row fetching.
If it wasn't for the per-row overhead, we could probably get rid of
Ex
On Thursday, January 12, 2023 7:08 PM Amit Kapila
wrote:
>
> On Thu, Jan 12, 2023 at 4:21 PM shveta malik wrote:
> >
> > On Thu, Jan 12, 2023 at 10:34 AM Amit Kapila
> wrote:
> > >
> > > On Thu, Jan 12, 2023 at 9:54 AM Peter Smith
> wrote:
> > > >
> > > >
> > > > doc/src/sgml/monitoring.sgml
On Thursday, January 12, 2023 12:24 PM Peter Smith
wrote:
>
> Hi, here are some review comments for patch v78-0001.
Thanks for your comments.
> ==
>
> General
>
> 1. (terminology)
>
> AFAIK everywhere until now we’ve been referring everywhere
> (docs/comments/code) to the parent apply w
Hi,
I've a question about 032_apply_delay.pl.
+# Test ALTER SUBSCRIPTION. Delay 86460 seconds (1 day 1 minute).
> +$node_subscriber->safe_psql('postgres',
> +"ALTER SUBSCRIPTION tap_sub SET (min_apply_delay = 8646)"
> +);
> +
> +# New row to trigger apply delay.
> +$node_publisher->safe_p
On Thu, 12 Jan 2023 at 11:59, Gurjeet Singh wrote:
>
> On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
> wrote:
> >
> > On Thu, 12 Jan 2023 at 10:16, Gurjeet Singh wrote:
> > >
> > > Technically correct name of this feature would be Readable Names for
> > > Operators, or Pronounceable Name
Thanks for the feedback and I apologize for the delay in response.
>I think the problem here is that you're basically trying to work around the
>lack of an asynchronous state update mechanism between leader and workers.
> The
>workaround is to add a lot of different places that poll w
On 2023-01-12 Th 00:12, Justin Pryzby wrote:
> On Wed, Jan 11, 2023 at 10:45:33PM -0500, Tom Lane wrote:
>> Amit Langote writes:
>>> On Thu, Jan 12, 2023 at 10:06 AM Tom Lane wrote:
I've pushed this with some cleanup --- aside from fixing
outfuncs/readfuncs, I did some more work on t
Hi,
On Thu, Jan 12, 2023 at 5:29 PM Drouvot, Bertrand
wrote:
>
> Hi,
>
> On 1/11/23 7:04 PM, Drouvot, Bertrand wrote:
> > Hi,
> >
> > Please find V38 attached, I'll look at the other comments you've done in
> > [1] on 0004 and 0006.
> >
> >
Sorry for joining late. I totally missed it. AFAICU, w
On Thu, Jan 12, 2023 at 5:21 PM John Naylor
wrote:
>
> On Thu, Jan 12, 2023 at 12:44 PM Masahiko Sawada
> wrote:
> >
> > On Wed, Jan 11, 2023 at 12:13 PM John Naylor
> > wrote:
> > >
> > > On Tue, Jan 10, 2023 at 7:08 PM Masahiko Sawada
> > > wrote:
>
> > I agree to keep this as a template.
>
Andrew Dunstan writes:
> On 2023-01-12 Th 00:12, Justin Pryzby wrote:
>> It's ugly and a terrible hack, and I don't know whether anyone would say
>> it's good enough, but one could can probably avoid the diff like:
>> sed -r '/CREATE/,/^$/{ s/\w+\.//g }'
> That looks quite awful. I don't think yo
On Thu, Jan 12, 2023 at 6:23 AM Pavel Stehule
wrote:
>
>
> st 11. 1. 2023 v 22:11 odesílatel Tom Lane napsal:
>
>> Pavel Stehule writes:
>> > st 11. 1. 2023 v 19:31 odesílatel Magnus Hagander
>> > napsal:
>> >> This is only about Internal and C, isn't it? Isn't the oid of these
>> >> static, a
Hi Matthias,
I'm going to look at this patch series if you're still interested. What was
the status of your final performance testing for the 0008 patch alone vs the
specialization series? Last I saw on the thread you were going to see if the
specialization was required or not.
Best,
David
On Wed, Jan 11, 2023 at 7:53 PM David G. Johnston
wrote:
> Justed wanted to chime in and say Robert has eloquently put into words much
> of what I have been thinking here, and that I concur that guiding the DBA to
> use care with the power they have been provided is a sane position to take.
>
>
Hi hackers,
I was running static analyser against PostgreSQL and found there're 2
return statements in PL/Python module which is not safe. Patch is
attached.
--
Best Regards,
Xing
diff --git a/src/pl/plpython/plpy_exec.c b/src/pl/plpython/plpy_exec.c
index 923703535a..c0e4a81283 100644
--- a/src
Matthias van de Meent writes:
> I'm -1 on the chosen syntax; :name: shadows common variable
> substitution patterns including those of psql.
Yeah, this syntax is DOA because of that. I think almost
anything you might invent is going to have conflict risks.
We could probably make it work by allo
On Thu, Jan 12, 2023 at 12:09 AM Noah Misch wrote:
> I think this is good to go modulo one or two things:
>
> > Subject: [PATCH v2] More documentation update for GRANT ... WITH SET OPTION.
> >
> > Update the reference pages for various ALTER commands that
> > mentioned that you must be a member of
On Thu, Jan 12, 2023 at 3:59 AM Gurjeet Singh wrote:
> On Thu, Jan 12, 2023 at 1:49 AM Matthias van de Meent
> wrote:
>
> > I'm -1 on the chosen syntax; :name: shadows common variable
> > substitution patterns including those of psql.
>
> I'll consider using one of the other special characters.
Paul Ramsey writes:
> On Mon, Jan 2, 2023 at 2:03 PM Dag Lem wrote:
>
>> I also improved on the documentation example (using Full Text Search).
>> AFAIK you can't make general queries like that using arrays, however in
>> any case I must admit that text arrays seem like more natural building
>>
On Wed, Jan 11, 2023 at 1:14 AM Noah Misch wrote:
> If the patch had just made postgres.h include varatt.h, like it does elog.h,
> I'd consider that change a nonnegative. Grouping things is nice, even if it
> makes compilation a bit slower. That also covers your frontend use case. How
> about t
On Thursday, January 12, 2023 12:04 PM Kyotaro Horiguchi
wrote:
> At Wed, 11 Jan 2023 12:46:24 +, "Hayato Kuroda (Fujitsu)"
> wrote in
> > them. Which version is better?
>
>
> Some comments by a quick loock, different from the above.
Horiguchi-san, thanks for your review !
> + CO
Vigneshk Kvignesh writes:
> I'm migrating our existing PG instances from PG11.4 to PG14.3. I
> have around 5 Million Tables in a single database. When migrating using
> pg_upgrade, its taking 3 hours for the process to complete. I'm not sure if
> its the intended behaviour or we're missing
> On Jan 12, 2023, at 7:30 AM, Dag Lem wrote:
>
> Paul Ramsey writes:
>
>> On Mon, Jan 2, 2023 at 2:03 PM Dag Lem wrote:
>>
>>> I also improved on the documentation example (using Full Text Search).
>>> AFAIK you can't make general queries like that using arrays, however in
>>> any case I
Hi, Shveta
Thanks for your comments!
On Thursday, January 12, 2023 6:51 PM shveta malik
wrote:
> > Yes, DBAs may set wal_receiver_status_interval to more than
> > wal_sender_timeout by mistake.
> >
> > But to handle the scenario we must compare between min_apply_delay *on
> > subscriber* and wa
On Thu, Jan 12, 2023 at 09:54:09AM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2023-01-12 Th 00:12, Justin Pryzby wrote:
> >> It's ugly and a terrible hack, and I don't know whether anyone would say
> >> it's good enough, but one could can probably avoid the diff like:
> >> sed -r '/CRE
Justin Pryzby writes:
> What about also including a dump from an old version, too ?
> Then the upgrade test can test actual upgrades.
The BF clients already do that (if enabled), but they work from
up-to-date installations of the respective branch tips. I'd not
want to have some branches includi
Hi, Melih
On Thursday, January 12, 2023 10:12 PM Melih Mutlu
wrote:
> I've a question about 032_apply_delay.pl.
> ...
> I couldn't quite see how these lines test whether ALTER SUBSCRIPTION
> successfully worked.
> Don't we need to check that min_apply_delay really changed as a result?
Yeah, we
Unfortunately, cirrus-ci still not happy
https://cirrus-ci.com/task/6502730475241472
[23:14:34.206] time make -s -j${BUILD_JOBS} world-bin
[23:14:43.174] psqlscanslash.l: In function ‘evaluate_backtick’:
[23:14:43.174] psqlscanslash.l:827:11: error: implicit declaration of
function ‘WIFSTOPPED’ [-
On 10.01.23 09:48, Peter Eisentraut wrote:
On 10.01.23 08:39, Noah Misch wrote:
On Tue, Jan 10, 2023 at 06:07:49AM +0100, Peter Eisentraut wrote:
On 30.12.22 17:50, Tom Lane wrote:
Peter Eisentraut writes:
On 28.12.22 16:07, Tom Lane wrote:
I dunno, #3 seems kind of unprincipled. Also, sinc
On 10.01.23 18:26, Mark Dilger wrote:
I wonder if logical replication could be made to work more easily with this
feature. Specifically, subscribers of encrypted columns will need the
encrypted column encryption key (CEK) and the name of the column master key
(CMD) as exists on the publisher,
On 23.11.22 21:32, Joe Conway wrote:
Yeah. Also, I don't think it's generally too hard to find the parent
process anyway, because at least on my system, the other ones end up
with ps display that looks like "postgres: logical replication
launcher" or whatever. The main process doesn't set the ps
On Thu, 12 Jan 2023 at 05:59, Gurjeet Singh wrote:
I'll consider using one of the other special characters. Do you have
> any suggestions?
>
What about backticks (`)? They are allowed as operator characters but do
not otherwise appear in the lexical syntax as far as I can tell:
https://www.postg
On Thu, 12 Jan 2023 at 10:04, Magnus Hagander wrote:
We could shorten it to "See \sf" or something like that. But if we change
>>> the column header to "internal name" or the like, then the column just
>>> obviously doesn't apply for non-internal languages, so leaving it null
>>> should be fine.
On Mon, Jan 9, 2023 at 8:40 PM Peter Geoghegan wrote:
> That's not what the patch does. It doubles the time that the anti-wrap
> no-autocancellation behaviors kick in, up to a maximum of 1 billion
> XIDs/MXIDs. So it goes from autovacuum_freeze_max_age to
> autovacuum_freeze_max_age x 2, without c
Isaac Morland writes:
> What about backticks (`)? They are allowed as operator characters but do
> not otherwise appear in the lexical syntax as far as I can tell:
> https://www.postgresql.org/docs/current/sql-syntax-lexical.html
Since they're already allowed as operator characters, you can't
use
On 12.01.23 01:04, Nathan Bossart wrote:
-classoid == AggregateRelationId ||
I noticed that AggregateRelationId isn't listed in the ObjectProperty
array, so I think recordExtObjInitPriv() will begin erroring for that
classoid instead of ignoring it like we do today.
Hmm
On 2023-Jan-12, Drouvot, Bertrand wrote:
> Please find attached a patch to $SUBJECT.
>
> It is a preliminary patch for [1].
>
> The main ideas are: 1) to have consistent naming between the pg_stat_get*()
> functions
> and their associated counters and 2) to define the new macros in [1] the same
On 2023-01-12 Th 09:54, Tom Lane wrote:
>
> I was wondering whether we could store a per-version patch or Perl
> script that edits the old dump file to remove known discrepancies
> from HEAD. If well-maintained, that could eliminate the need for the
> arbitrary "fuzz factors" that are in TestUpg
Peter Eisentraut writes:
> On 12.01.23 01:04, Nathan Bossart wrote:
> - classoid == AggregateRelationId ||
>> I noticed that AggregateRelationId isn't listed in the ObjectProperty
>> array, so I think recordExtObjInitPriv() will begin erroring for that
>> classoid instead of i
Alvaro Herrera writes:
> I don't like this at all. With these prefixes in place, it's much more
> likely that you'll be able to grep the whole source tree and not run
> into tons of false positives. If you remove them, that tends to be not
> very workable. If we use these commits as precedent f
Andrew Dunstan writes:
> On 2023-01-12 Th 09:54, Tom Lane wrote:
>> I was wondering whether we could store a per-version patch or Perl
>> script that edits the old dump file to remove known discrepancies
>> from HEAD.
> so, say in src/test/perl we have PostgreSQL/AdjustUpgrade.pm with a
> subrout
On Thu, Jan 12, 2023 at 12:20:50PM -0500, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 12.01.23 01:04, Nathan Bossart wrote:
>> - classoid == AggregateRelationId ||
>>> I noticed that AggregateRelationId isn't listed in the ObjectProperty
>>> array, so I think recordExtObjI
On 1/12/23 18:14, Tom Lane wrote:
Pretty much the only available syntax space is curly braces,
and I don't really want to give those up for this either.
(One has to assume that the SQL committee has their eyes
on those too.)
They are used in row pattern recognition.
--
Vik Fearing
On 2023-Jan-11, Peter Eisentraut wrote:
> How does one decide whether something should be in a schema or not? The
> current state feels intuitively correct, but I can't determine any firm way
> to decide.
>
> Over in the column encryption thread, the patch proposes to add various key
> types as
Hi,
On 2023-01-12 18:12:52 +0100, Alvaro Herrera wrote:
> On 2023-Jan-12, Drouvot, Bertrand wrote:
>
> > Please find attached a patch to $SUBJECT.
> >
> > It is a preliminary patch for [1].
> >
> > The main ideas are: 1) to have consistent naming between the pg_stat_get*()
> > functions
> > and t
Hi,
On 2023-01-12 20:08:55 +0530, Ashutosh Sharma wrote:
> I previously participated in the discussion on "Synchronizing the
> logical replication slots from Primary to Standby" and one of the
> purposes of that project was to synchronize logical slots from primary
> to standby so that if failover
On Thu, Jan 12, 2023 at 03:30:40PM +0900, Michael Paquier wrote:
> On Wed, Jan 11, 2023 at 11:29:01AM -0800, Nathan Bossart wrote:
>> I initially created a separate basic_restore module, but decided to fold it
>> into basic_archive to simplify the patch and tests. I hesitated to rename
>> it becau
Hi,
On 2023-01-12 08:38:57 +0100, Drouvot, Bertrand wrote:
> On 1/11/23 11:59 PM, Andres Freund wrote:
> > > Now that this patch renames some fields
> >
> > I don't mind renaming the fields - the prefixes really don't provide
> > anything
> > useful. But it's not clear why this is related to thi
Hi,
On 2023-01-12 20:35:43 +1300, Thomas Munro wrote:
> Subject: [PATCH] Fix WaitEventSetWait() buffer overrun.
>
> The WAIT_USE_EPOLL and WAIT_USE_KQUEUE implementations of
> WaitEventSetWaitBlock() confused the size of their internal buffer with
> the size of the caller's output buffer, and cou
On 1/12/23 12:00, Peter Eisentraut wrote:
On 23.11.22 21:32, Joe Conway wrote:
Yeah. Also, I don't think it's generally too hard to find the parent
process anyway, because at least on my system, the other ones end up
with ps display that looks like "postgres: logical replication
launcher" or wha
On Thu, Jan 12, 2023 at 10:14 AM Tom Lane wrote:
> Isaac Morland writes:
> > What about backticks (`)? They are allowed as operator characters but do
> > not otherwise appear in the lexical syntax as far as I can tell:
> > https://www.postgresql.org/docs/current/sql-syntax-lexical.html
>
> Since
On Thu, Jan 12, 2023 at 11:19:29PM +0800, Xing Guo wrote:
> I was running static analyser against PostgreSQL and found there're 2
> return statements in PL/Python module which is not safe. Patch is
> attached.
Is the problem that PG_exception_stack and error_context_stack aren't
properly reset?
>
On Wed, Jan 11, 2023 at 1:03 PM Tom Lane wrote:
> Jacob Champion writes:
> > Right, I think it would have to be opt-in. Say, a new control file
> > option dump_version or some such.
>
> That would require all the installed extensions to cope with this
> the same way, which does not seem like a gr
Hi All,
Changes added to Jacob's patch(v2) as per the discussion in the thread.
The changes allow the customer to send the OAUTH BEARER token through psql
connection string.
Example:
psql -U u...@example.com -d 'dbname=postgres oauth_bearer_token=abc'
To configure OAUTH, the pg_hba.conf line l
Hi,
On Thu, 2023-01-12 at 13:35 -0500, Joe Conway wrote:
> To be clear, I am completely in agreement with you about removing the
> symlink. I just wanted to be sure Devrim was alerted because I knew
> he had a strong opinion on this topic ;-)
Red Hat's own packages, thus their users may be unhap
On Thu, Jan 12, 2023 at 9:12 AM Robert Haas wrote:
> I do agree that it's good to slowly increase the aggressiveness of
> VACUUM as we get further behind, rather than having big behavior
> changes all at once, but I think that should happen by smoothly
> varying various parameters rather than by m
On Sun, Dec 18, 2022 at 12:53:31PM -0800, Andrey Borodin wrote:
> I've rewritten this part to correctly report all timeouts that did
> happen. However there's now a tricky comma-formatting code which was
> tested only manually.
I suspect this will make translation difficult.
>> > > > + ahprin
Hi,
On 2023-01-11 23:03:30 -0800, Will Mortensen wrote:
> On Wed, Jan 11, 2023 at 12:33 PM Andres Freund wrote:
> > I think such a function would still have to integrate enough with the lock
> > manager infrastructure to participate in the deadlock detector. Otherwise I
> > think you'd trivially
On Thu, Jan 12, 2023 at 11:24 AM Nathan Bossart
wrote:
>
> On Sun, Dec 18, 2022 at 12:53:31PM -0800, Andrey Borodin wrote:
> > I've rewritten this part to correctly report all timeouts that did
> > happen. However there's now a tricky comma-formatting code which was
> > tested only manually.
>
> I
> On 11 Jan 2023, at 17:38, vignesh C wrote:
>
> On Tue, 29 Nov 2022 at 18:16, Daniel Gustafsson wrote:
>>
>>> On 3 Nov 2022, at 21:47, Daniel Gustafsson wrote:
>>
>>> The patch adds a new GUC, ignore_event_trigger with two option values, 'all'
>>> and 'none' (the login event patch had 'login
What's the distinction between errdetail and errdetail_log in the ereport
interface?
On 2023-01-12 12:28:39 -0800, Christophe Pettus wrote:
> What's the distinction between errdetail and errdetail_log in the ereport
> interface?
Only goes to the server log, not to the client.
On Thu, Jan 12, 2023 at 12:26 PM Daniel Gustafsson wrote:
> > On 11 Jan 2023, at 17:38, vignesh C wrote:
> >
> > On Tue, 29 Nov 2022 at 18:16, Daniel Gustafsson wrote:
> >>
> >>> On 3 Nov 2022, at 21:47, Daniel Gustafsson wrote:
> >>
> >>> The patch adds a new GUC, ignore_event_trigger with tw
> On Jan 12, 2023, at 12:35, Andres Freund wrote:
>
> On 2023-01-12 12:28:39 -0800, Christophe Pettus wrote:
>> What's the distinction between errdetail and errdetail_log in the ereport
>> interface?
>
> Only goes to the server log, not to the client.
Thanks!
On Thu, Jan 12, 2023 at 2:22 PM Peter Geoghegan wrote:
> All that I really want to do here is give an autovacuum that *can* be
> auto cancelled *some* non-zero chance to succeed with these kinds of
> tables. TRUNCATE completes immediately, so the AEL is no big deal.
> Except when it's blocked behi
On Fri, Jan 13, 2023 at 7:26 AM Andres Freund wrote:
> On 2023-01-12 20:35:43 +1300, Thomas Munro wrote:
> > Subject: [PATCH] Fix WaitEventSetWait() buffer overrun.
> Makes sense. We should backpatch this, I think?
Done.
On Thu, Jan 12, 2023 at 1:08 PM Robert Haas wrote:
> I doubt it. Wiggle room that's based on the XID threshold being
> different for one behavior vs. another can easily fail to produce any
> benefit, because there's no guarantee that the autovacuum launcher
> will ever try to launch a worker again
On 2022-11-29 6:16 p.m., Tom Lane wrote:
Assuming that you are inserting into index X, and you've checked
index Y to find that it has no conflicts, what prevents another
backend from inserting a conflict into index Y just after you look?
AIUI the idea is to prevent that by continuing to hold an e
Hi,
While working on the postmaster latch stuff, one of the things I
looked into, but de-scoped for now, is how the postmaster code would
look if it didn't use global variables to track its sockets, children
and state (ie now that it's no longer necessary for technical
reasons). Here's the quick
On Wed, Sep 14, 2022 at 7:54 AM Maxim Orlov wrote:
> For the patch itself, I think it is better to use a more precise time
> function in libpq_prng_init or call it only once.
> Thought it is a special corner case, imagine all the connection attempts at
> first second will be seeded with the save
On Wed, Oct 05, 2022 at 10:37:01AM +0200, Laurenz Albe wrote:
> On Mon, 2022-03-28 at 15:05 +0200, Tomas Vondra wrote:
>> I've pushed the last version, and backpatched it to 10 (not sure I'd
>> call it a bugfix, but I certainly agree with Justin it's worth
>> mentioning in the docs, even on older b
On Thu, Jan 12, 2023 at 05:29:39PM +0530, Bharath Rupireddy wrote:
> As discussed [1], here's a patch to beautify pg_walinspect docs
> similar to pageinspect docs. The existing pg_walinspect docs calls out
> the column names explicitly and then also shows them in the function
> execution examples w
On Thu, 12 Jan 2023 at 05:22, Michael Paquier wrote:
>
> On Wed, Jan 11, 2023 at 10:29:25PM +0530, vignesh C wrote:
> > I too felt keeping it simpler is better. How about using the simple
> > first version of patch itself?
>
> Okay, I have just done that, then, after checking that all the object
>
Hi,
This is a follow-up for commit c94ae9d8. It's in the spirit of other
recent changes to remove noise from ancient pre-standard systems.
The reason we introduced PG_SETMASK() in the first place was to
support one particular system that was very slow to adopt the POSIX
signals stuff: NeXTSTEP
On Thu, Jan 12, 2023 at 8:11 AM Robert Haas wrote:
> On Wed, Jan 11, 2023 at 7:53 PM David G. Johnston
> wrote:
> > Justed wanted to chime in and say Robert has eloquently put into words
> much of what I have been thinking here, and that I concur that guiding the
> DBA to use care with the power
On Thu, Jan 12, 2023 at 10:44:33AM -0800, Nathan Bossart wrote:
> There's another "return" later on in this PG_TRY block. I wonder if it's
> possible to detect this sort of thing at compile time.
Note also:
src/pl/tcl/pltcl.c- * PG_CATCH();
src/pl/tcl/pltcl.c- * {
src/pl/tcl/pltcl.c- *
On Sun, Feb 27, 2022 at 8:07 AM Tom Lane wrote:
> I have observed this three times in the REL_11 branch, once
> in REL_12, and a couple of times last summer before it occurred
> to me to start keeping notes. Over that time the machine has
> been running various patchlevels of FreeBSD 13.0.
FTR I
On Thu, Jan 12, 2023 at 10:10:02AM +0100, Jelte Fennema wrote:
> It also makes the code simpler as we can simply reuse the
> check_role function, since that. I removed the lines you quoted
> since those are actually not strictly necessary. They only change
> the detection logic a bit in case of a \
1 - 100 of 127 matches
Mail list logo
