Hi Hackers,
At present, calling pg_stat_reset* functions requires super user access
unless explicitly grant execute permission on those. In this thread, I am
proposing to grant execute on them to users with pg_monitor role
permissions. This comes handy to the monitoring users (part of pg_monitor
r
On Mon, 2022-11-21 at 11:42 +0530, Bharath Rupireddy wrote:
> On Mon, Nov 21, 2022 at 10:37 AM Laurenz Albe
> wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who wants to complain about dr
On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> >
> > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > I'll wait 24 hours before committing, to
> > > provide a last chance for anyone who wants to complain about dropping
> > >
Hi, hackers!
It is important for customer support to know what system operations
(pg_resetwal, pg_rewind, pg_upgrade, ...) have been executed on the
database. A variant of implementation of the log for system operations
(operation log) is attached to this email.
Introduction.
-
On Mon, Nov 21, 2022 at 4:20 PM John Naylor
wrote:
>
>
> On Fri, Nov 18, 2022 at 2:48 PM I wrote:
> > One issue with this patch: The "fanout" member is a uint8, so it can't hold
> > 256 for the largest node kind. That's not an issue in practice, since we
> > never need to grow it, and we only co
On 2022-Nov-20, sirisha chamarthi wrote:
> Hi Hackers,
>
> forking this thread from the discussion [1] as suggested by Amit.
>
> Catalog_xmin is not advanced when a logical slot is invalidated (lost)
> until the invalidated slot is dropped. This patch ignores invalidated slots
> while computing
On 21.11.22 00:57, Heikki Linnakangas wrote:
On 19/11/2022 13:00, Peter Eisentraut wrote:
On 18.10.21 14:15, Heikki Linnakangas wrote:
On 05/10/2021 20:24, John Naylor wrote:
I've had a chance to review and test out the v5 patches.
Thanks! I fixed the stray reference to PostgreSQL 14 that Zh
On Mon, Nov 21, 2022 at 3:43 PM Masahiko Sawada
wrote:
>
> On Mon, Nov 21, 2022 at 4:20 PM John Naylor
> wrote:
> > Assuming the smallest node is fixed size (i.e. fanout/capacity member
not part of the common set, so only part of variable-sized nodes), 3 has a
nice property: no wasted padding sp
On Sun, Nov 20, 2022 at 03:15:34PM -0800, Ted Yu wrote:
> + * timestamp. These require a specific handling with their typmod is given
> + * by the function caller through their SQL keyword.
>
> typo: typmod is given -> typmod given
>
> Other than the above, code looks good to me.
Thanks for dou
> I have a very serious concern about the current patch set. as someone who has
> faced transaction id wraparound in the past.
>
> I can start by saying I think it would be helpful (if the other issues are
> approached reasonably) to have 64-bit xids, but there is an important piece
> of context
On Fri, 2022-11-18 at 14:28 -0500, Bruce Momjian wrote:
> New patch attached.
Thanks.
> --- a/doc/src/sgml/ref/release_savepoint.sgml
> +++ b/doc/src/sgml/ref/release_savepoint.sgml
> + RELEASE SAVEPOINT releases the named savepoint and
> + all active savepoints that were created after the n
Agreed on not using "unaborted", per previous discussion.
On 2022-Nov-21, Laurenz Albe wrote:
> Perhaps we should also avoid the term "transaction block". Even without
> speaking
> of a "block", way too many people confuse PL/pgSQL's BEGIN ... END blocks
> with transactions. On the other hand,
See also prior discussions:
https://www.postgresql.org/message-id/flat/62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel%40j-davis.com
https://www.postgresql.org/message-id/flat/20180228214311.jclah37cwh572t2c%40alap3.anarazel.de
--
Justin
Hi,
I noticed that the comment on/beneath rs_numblocks in HeapScanDescData
is duplicated above rs_strategy. I don't know if there should have
been a different comment above rs_strategy, but the current one is
definitely out of place, so I propose to remove it as per attached.
The comment was dupl
Hi hackers,
> > I have a very serious concern about the current patch set. as someone who
> > has faced transaction id wraparound in the past.
>
> [...]
>
> I had a similar stance when I started working on this patch. Of
> course, it seemed horrible just to postpone the consequences of
> inadequa
Hi Sirisha,
Thanks for identifying the bug and the solution. Some review comments inlined.
On Mon, Nov 21, 2022 at 2:49 PM Alvaro Herrera wrote:
>
> On 2022-Nov-20, sirisha chamarthi wrote:
>
> > Hi Hackers,
> >
> > forking this thread from the discussion [1] as suggested by Amit.
> >
> > Catalo
On Mon, 21 Nov 2022 at 12:12, Matthias van de Meent
wrote:
>
> Hi,
>
> I noticed that the comment on/beneath rs_numblocks in HeapScanDescData
> is duplicated above rs_strategy. I don't know if there should have
> been a different comment above rs_strategy, but the current one is
> definitely out o
On Sat, Nov 19, 2022 at 6:47 PM Stavros Koureas
wrote:
>
> Hi all,
>
> Working with PostgreSQL Logical Replication is just great! It helps a lot
> doing real time replication for analytical purposes without using any other
> 3d party service. Although all these years working as product architect
On Mon, 21 Nov 2022 at 08:40, Laurenz Albe wrote:
>
> On Mon, 2022-11-21 at 07:36 +, Simon Riggs wrote:
> > On Mon, 21 Nov 2022 at 05:07, Laurenz Albe wrote:
> > >
> > > On Mon, 2022-11-21 at 10:13 +1300, Thomas Munro wrote:
> > > > I'll wait 24 hours before committing, to
> > > > provide a l
Hi hackers,
the case of planner's
src/backend/utils/adt/selfuncs.c:get_actual_variable_endpoint()
spending literally seconds seems to be well known fact across hackers
(in the extreme wild case it can be over 1+ hour on VLDBs). For those
unfamiliar it is planner estimation that tries to read real
On 2022-Nov-21, Ashutosh Bapat wrote:
> I think the condition should be
>
> if (!XLogRecPtrIsInvalid(invalidated_at_lsn)) LSN and XID are
> different data types.
Yeah, this bit is wrong. I agree with your suggestion to just keep a
boolean flag, as we don't need more than that.
> and to be inli
On 2022-Nov-21, Jakub Wartak wrote:
> b) I was wondering about creating a new wait class "Planner" with the
> event "ReadingMinMaxIndex" (or similar). The obvious drawback is the
> naming/categorization as wait events are ... well.. as the name "WAIT"
> implies, while those btree lookups could eas
On Mon, Nov 21, 2022 at 5:39 PM Alvaro Herrera wrote:
>
> On 2022-Nov-21, Ashutosh Bapat wrote:
>
> > I think the condition should be
> >
> > if (!XLogRecPtrIsInvalid(invalidated_at_lsn)) LSN and XID are
> > different data types.
>
> Yeah, this bit is wrong. I agree with your suggestion to just k
On Thu, 17 Nov 2022 at 22:01, Cary Huang wrote:
>
> Patch: Global Unique Index
Let me start by expressing severe doubt on the usefulness of such a
feature, but also salute your efforts to contribute.
> In other words, a global unique index and a regular partitioned index are
> essentially the s
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
i've tested and verified the documentation.
On Friday, November 18, 2022 8:36 AM Masahiko Sawada
wrote:
>
> Here are review comments on v47-0001 and v47-0002 patches:
Thanks for the comments!
> When the parallel apply worker exited, I got the following server log.
> I think this log is not appropriate since the worker was not terminated
On Monday, November 21, 2022 2:26 PM Peter Smith wrote:
> On Fri, Nov 18, 2022 at 6:03 PM Peter Smith
> wrote:
> >
> > Here are some review comments for v47-0001
> >
> > (This review is a WIP - I will post more comments for this patch next
> > week)
> >
>
> Here are the rest of my comments for
On Mon, Nov 21, 2022 at 9:03 PM Amit Langote wrote:
> On Thu, Nov 10, 2022 at 8:58 PM Alvaro Herrera
> wrote:
> > Why do callers of add_rte_to_flat_rtable() have to modify the rte's
> > perminfoindex themselves, instead of having the function do it for them?
> > That looks strange. But also it'
Hi!
PREAMBLE
For a last couple of months, I stumbled into a problem while running tests
on ARM (Debain, aarch64) and some more wired platforms
for my 64–bit XIDs patch set. Test contrib/test_decoding
(catalog_change_snapshot) rarely failed with the next message:
TRAP: FailedAssertion("Transacti
> Pushed.
>
> --
> With Regards,
> Amit Kapila.
>
>
Hi!
While working on 64–bit XID's patch set, I stumble into problems with
contrib/test_decoding/catalog_change_snapshot test [0].
AFAICS, the problem is not related to the 64–bit XID's patch set and the
problem is in InitialRunningXacts array, a
Hi,
On 11/21/22 12:19 AM, Andres Freund wrote:
Hi,
On 2022-11-18 12:18:38 +0100, Drouvot, Bertrand wrote:
On 11/16/22 9:12 PM, Andres Freund wrote:
This still leaves a fair bit of boilerplate. ISTM that the function body
really should just be a single line.
Might even be worth defining the w
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I've looked at this patch and don't see any problems with it. It is m
On Fri, 18 Nov 2022 at 18:26, Tom Lane wrote:
>
> Robert Haas writes:
> > On Fri, Nov 18, 2022 at 7:04 AM Simon Riggs
> > wrote:
> >> So if consistency is also a strong requirement, then maybe we should
> >> make that new command the default, i.e. make VACUUM always just a
> >> request to vacuum
Andres Freund writes:
> But either way, it seems nicer to output the # inside a helper function?
Note that the helper function should inject '# ' at the start of every
line in the message, not just the first line. It might also be worth
having two separate functions: one that prints to stdout,
Thanks for references, Justin!
Couple comments about these references.
1) "Make unlogged table resets detectable".
https://www.postgresql.org/message-id/flat/62750df5b126e1d8ee039a79ef3cc64ac3d47cd5.camel%40j-davis.com
This conversation is about specific problem (unlogged table repairing).
Ope
> On 10 Aug 2022, at 10:28, Daniel Gustafsson wrote:
>
>> On 10 Aug 2022, at 08:12, Kyotaro Horiguchi wrote:
>>
>> (I suppose this is a pg15 issue)
>>
>> createuser --help shows the following help text.
>>
>>> --bypassrls role can bypass row-level security (RLS) policy
>>> --no-
On 2022-Nov-21, Ashutosh Bapat wrote:
> Maybe. In that case pg_get_replication_slots() should be changed. We
> should use the same criteria to decide whether a slot is invalidated
> or not at all the places.
Right.
> I am a fan of stricter, all-assumption-covering conditions. In case we
> don't
Justin Pryzby писал 2022-11-21 06:00:
I finally found time to digest and integrate your changes into my local
branch. This fixes the three issues you reported: FORCE_RELEASE, issue
with INVALID partitions issue (for which I adapted your patch into an
earlier patch in my series), and progress rep
On Mon, Nov 21, 2022 at 7:22 AM Alvaro Herrera wrote:
> On 2022-Nov-21, Jakub Wartak wrote:
> > b) I was wondering about creating a new wait class "Planner" with the
> > event "ReadingMinMaxIndex" (or similar). The obvious drawback is the
> > naming/categorization as wait events are ... well.. as
Robert Haas writes:
> I don't think this is safe at all. Wait events can only bracket
> individual operations, like the reads of the individual index blocks,
> not report on which phase of a larger operation is in progress. If we
> try to make them do the latter, we will have a hot mess on our han
On Fri, 18 Nov 2022 at 11:54, Simon Riggs wrote:
>
> On Thu, 17 Nov 2022 at 20:00, Justin Pryzby wrote:
> >
> > On Wed, Nov 16, 2022 at 05:14:07PM -0500, Greg Stark wrote:
> > > I think this requesting autovacuum worker should be a distinct
> > > command. Or at least an explicit option to vacuum.
On Mon, 21 Nov 2022 at 15:01, Tom Lane wrote:
>
> > What we need is a solution that avoids reading an unbounded number of
> > tuples under any circumstances. I previously suggested using
> > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > safety issues there or if Tom was
Thanks Alvaro, Ashutosh for your comments.
On Mon, Nov 21, 2022 at 6:20 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, Ashutosh Bapat wrote:
>
> > Maybe. In that case pg_get_replication_slots() should be changed. We
> > should use the same criteria to decide whether a slot is invalidated
> > or no
Hi everyone,
I have made a patch that introduces support for libpq binary protocol
in postgres_fdw. The idea is simple, when a user knows that the foreign
server is binary compatible with the local and his workload could
somehow benefit from using binary protocol, it can be switched on for a
parti
On Mon, Nov 21, 2022 at 10:14 AM Simon Riggs
wrote:
> > > What we need is a solution that avoids reading an unbounded number of
> > > tuples under any circumstances. I previously suggested using
> > > SnapshotAny here, but Tom didn't like that. I'm not sure if there are
> > > safety issues there o
On Mon, 21 Nov 2022 at 15:23, Robert Haas wrote:
>
> On Mon, Nov 21, 2022 at 10:14 AM Simon Riggs
> wrote:
> > > > What we need is a solution that avoids reading an unbounded number of
> > > > tuples under any circumstances. I previously suggested using
> > > > SnapshotAny here, but Tom didn't li
On 11/20/22 2:56 PM, Andres Freund wrote:
Hi,
On 2022-11-09 17:03:13 -0800, Andres Freund wrote:
On 2022-11-09 09:38:08 -0800, Andres Freund wrote:
I'm on a hike, without any connectivity, Thu afternoon - Sun. I think it's OK
to push it to HEAD if I get it done in the next few hours. Bigger is
Robert Haas writes:
> Is there any reason to tie this into page costs? I'd be more inclined
> to just make it a hard limit on the number of pages. I think that
> would be more predictable and less prone to surprising (bad) behavior.
Agreed, a simple limit of N pages fetched seems appropriate.
>
On Sun, Nov 20, 2022 at 6:10 PM Andres Freund wrote:
> I was wondering about that too - but decided against it because it would only
> show a single wait event. And wouldn't really describe spinlocks as a whole,
> just the "extreme" delays. If we wanted to report the spin waits more
> granular, we
On Mon, Nov 21, 2022 at 10:32 AM Tom Lane wrote:
> Robert Haas writes:
> > Is there any reason to tie this into page costs? I'd be more inclined
> > to just make it a hard limit on the number of pages. I think that
> > would be more predictable and less prone to surprising (bad) behavior.
>
> Agr
On Sat, Nov 19, 2022 at 1:00 AM Michael Paquier wrote:
> On Fri, Nov 18, 2022 at 04:19:15PM -0500, Robert Haas wrote:
> > Fixed that, and the other mistake Álvaro spotted, and also bumped
> > catversion because I forgot that earlier.
>
> I was looking at this code yesterday, to see today that psql
On 2022-Nov-21, sirisha chamarthi wrote:
> > > I am a fan of stricter, all-assumption-covering conditions. In case we
> > > don't want to check restart_lsn, an Assert might be useful to validate
> > > our assumption.
> >
> > Agreed. I'll throw in an assert.
>
> Changed this in the patch to throw
Hi,
Draft version of the patch attached (it is based on Simon's)
I would be happier if we could make that #define into GUC (just in
case), although I do understand the effort to reduce the number of
various knobs (as their high count causes their own complexity).
-Jakub Wartak.
On Mon, Nov 21, 2
On Mon, Nov 21, 2022 at 3:40 AM Laurenz Albe wrote:
> We have had a deprecation period? I looked at the documentation, but found
> no mention of a deprecation. How hard can it be to leave the GUC and only
> poll for the existence of the file if it is set?
>
> I personally don't need the GUC, and
On Mon, Nov 21, 2022 at 8:05 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, sirisha chamarthi wrote:
>
> > > > I am a fan of stricter, all-assumption-covering conditions. In case
> we
> > > > don't want to check restart_lsn, an Assert might be useful to
> validate
> > > > our assumption.
> > >
> > >
I wrote:
> Andres Freund writes:
>> I suspect that having a GUC would be a good idea. I needed something similar
>> recently, debugging an occasional hang in the AIO patchset. I first tried
>> something like your #define approach and it did cause a problematic flood of
>> core files.
> Yeah, the
On Sun, Nov 20, 2022 at 9:20 PM Kyotaro Horiguchi
wrote:
> I prefer Robert's approach as it is more robust for future changes and
> simple. I prefer to avoid this kind of piggy-backing and it doesn't
> seem to be needed in this case. XLogShutdownWalRcv() looks like a
> similar case to me and hones
Robert Haas writes:
> The reason that I pushed back -- not as successfully as I would have
> liked -- on the changes to pg_stop_backup / pg_start_backup is that I
> know there are people using the old method successfully, and it's not
> just a 1:1 substitution. Here I don't, and it is. I'm totally
On 2022-Nov-21, sirisha chamarthi wrote:
> On Mon, Nov 21, 2022 at 8:05 AM Alvaro Herrera
> wrote:
> > Thank you. I had pushed mine for CirrusCI to test, and it failed the
> > assert I added in slot.c:
> > https://cirrus-ci.com/build/4786354503548928
> > Not yet sure why, looking into it.
>
>
Hi,
On 2022-11-21 17:06:16 +0100, Jakub Wartak wrote:
> @@ -6213,14 +6216,26 @@ get_actual_variable_endpoint(Relation heapRel,
> /* Fetch first/next tuple in specified direction */
> while ((tid = index_getnext_tid(index_scan, indexscandir)) != NULL)
> {
> + BlockNumb
This patch version runs "continue" unconditionally (rather than
conditionally, like the previous version).
if (!index_fetch_heap(index_scan, tableslot))
continue; /* no visible tuple,
try next index entry */
I wrote:
> Andres Freund writes:
>> Looks like a chunk of the buildfarm doesn't like this - presumably because
>> they use force_parallel_mode = regress. Seems ok to just force that to off in
>> this test?
> Ugh ... didn't occur to me to try that. I'll take a look.
Hmm, so the problem is:
SELE
On Mon, Nov 21, 2022 at 9:12 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, sirisha chamarthi wrote:
>
> > On Mon, Nov 21, 2022 at 8:05 AM Alvaro Herrera
> > wrote:
>
> > > Thank you. I had pushed mine for CirrusCI to test, and it failed the
> > > assert I added in slot.c:
> > > https://cirrus-ci.c
On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> This can't quite be right - isn't this only applying the limit if we found a
> visible tuple?
It doesn't look that way to me, but perhaps I'm just too dense to see
the problem?
--
Robert Haas
EDB: http://www.enterprisedb.com
Andres Freund writes:
> This can't quite be right - isn't this only applying the limit if we found a
> visible tuple?
What it's restricting is the number of heap page fetches, which
might be good enough. We don't have a lot of visibility here
into how many index pages were scanned before returni
On Mon, Nov 21, 2022 at 12:38 PM Tom Lane wrote:
> Andres Freund writes:
> > This can't quite be right - isn't this only applying the limit if we found a
> > visible tuple?
>
> What it's restricting is the number of heap page fetches, which
> might be good enough. We don't have a lot of visibili
Robert Haas writes:
> On Mon, Nov 21, 2022 at 12:38 PM Tom Lane wrote:
>> What it's restricting is the number of heap page fetches, which
>> might be good enough. We don't have a lot of visibility here
>> into how many index pages were scanned before returning the next
>> not-dead index entry, s
On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> Looks like a chunk of the buildfarm doesn't like this - presumably because
> >> they use force_parallel_mode = regress. Seems ok to just force that to off
> >> in
> >> this test?
>
> > Ugh ... didn't occur
Robert Haas writes:
> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote:
>> Hmm, so the problem is:
>>
>> SELECT octet_length(get_raw_page('test1', 'main', 0)) AS main_0;
>> ERROR: cannot access temporary tables during a parallel operation
>>
>> Why in the world is get_raw_page() marked as paral
On 2022-Nov-21, sirisha chamarthi wrote:
> It appears to be. wal_sender is setting restart_lsn to a valid LSN even
> when the slot is invalidated.
> postgres@pgvm:~$ /usr/local/pgsql/bin/pg_receivewal -S s1 -D .
> pg_receivewal: error: unexpected termination of replication stream: ERROR:
> reque
Hi,
On November 21, 2022 9:37:34 AM PST, Robert Haas wrote:
>On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
>> This can't quite be right - isn't this only applying the limit if we found a
>> visible tuple?
>
>It doesn't look that way to me, but perhaps I'm just too dense to see
>the probl
On Mon, Nov 21, 2022 at 10:11 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, sirisha chamarthi wrote:
>
> > It appears to be. wal_sender is setting restart_lsn to a valid LSN even
> > when the slot is invalidated.
>
> > postgres@pgvm:~$ /usr/local/pgsql/bin/pg_receivewal -S s1 -D .
> > pg_receivewal:
On Mon, 21 Nov 2022 at 18:17, Andres Freund wrote:
>
> Hi,
>
> On November 21, 2022 9:37:34 AM PST, Robert Haas
> wrote:
> >On Mon, Nov 21, 2022 at 12:30 PM Andres Freund wrote:
> >> This can't quite be right - isn't this only applying the limit if we found
> >> a
> >> visible tuple?
> >
> >It
On Mon, Nov 21, 2022 at 10:40 AM sirisha chamarthi <
sirichamarth...@gmail.com> wrote:
>
>
> On Mon, Nov 21, 2022 at 10:11 AM Alvaro Herrera
> wrote:
>
>> On 2022-Nov-21, sirisha chamarthi wrote:
>>
>> > It appears to be. wal_sender is setting restart_lsn to a valid LSN even
>> > when the slot is
On 2022-Nov-21, sirisha chamarthi wrote:
> I have a old .partial file in the data directory to reproduce this.
I don't think the .partial file is in itself important. But I think
this whole thing is a distraction. I managed to reproduce it
eventually, by messing with the slot and WAL at random,
On Mon, Nov 21, 2022 at 10:56 AM Alvaro Herrera
wrote:
> On 2022-Nov-21, sirisha chamarthi wrote:
>
> > I have a old .partial file in the data directory to reproduce this.
>
> I don't think the .partial file is in itself important. But I think
> this whole thing is a distraction.
Yes, sorry for
Question about
"""
Subject: [PATCH v50 5/8] Add initdb option to initialize cluster with
non-standard xid/mxid/mxoff.
To date testing database cluster wraparund was not easy as initdb has always
inited it with default xid/mxid/mxoff. The option to specify any valid
xid/mxid/mxoff at cluster sta
Hi,
On November 21, 2022 10:44:17 AM PST, Simon Riggs
wrote:
>Robert, something like this perhaps? limit on both the index and the heap.
I don't think we should add additional code / struct members into very common
good paths for these limits.
I don't really understand the point of limiting
I wrote:
> I'll check to see if any sibling functions have the same issue,
> and push a patch to adjust them.
> Presumably the parallel labeling has to be fixed as far back as
> it's marked that way (didn't look). Maybe we should push the
> test change further back too, just to exercise this.
Hmm
Andres Freund writes:
> On November 21, 2022 10:44:17 AM PST, Simon Riggs
> wrote:
>> Robert, something like this perhaps? limit on both the index and the heap.
> I don't think we should add additional code / struct members into very common
> good paths for these limits.
Yeah, I don't like t
Peter Eisentraut writes:
>> To date testing database cluster wraparund was not easy as initdb has always
>> inited it with default xid/mxid/mxoff. The option to specify any valid
>> xid/mxid/mxoff at cluster startup will make these things easier.
> Doesn't pg_resetwal already provide that functio
Hello,
The operator `IS NULL` doesn't work if the argument has unknown type.
In psycopg 3:
>>> conn.execute("select %s is null", ['foo']).fetchone()
IndeterminateDatatype: could not determine data type of parameter $1
This can get in the way of using the unknown type for strings (but
spe
Hi,
On 2022-11-21 12:52:01 -0500, Robert Haas wrote:
> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote:
> > I wrote:
> > > Andres Freund writes:
> > >> Looks like a chunk of the buildfarm doesn't like this - presumably
> > >> because
> > >> they use force_parallel_mode = regress. Seems ok to ju
Daniele Varrazzo writes:
> The operator `IS NULL` doesn't work if the argument has unknown type.
> conn.execute("select %s is null", ['foo']).fetchone()
> IndeterminateDatatype: could not determine data type of parameter $1
Yeah.
> It doesn't seem necessary to specify a type for an argument
Hi,
On 2022-11-21 12:34:12 +0100, Matthias van de Meent wrote:
> On Mon, 21 Nov 2022 at 12:12, Matthias van de Meent
> wrote:
> >
> > Hi,
> >
> > I noticed that the comment on/beneath rs_numblocks in HeapScanDescData
> > is duplicated above rs_strategy. I don't know if there should have
> > been
Andres Freund writes:
> On 2022-11-21 12:52:01 -0500, Robert Haas wrote:
>> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote:
>>> Why in the world is get_raw_page() marked as parallel safe?
>>> It clearly isn't, given this restriction.
> It's somewhat sad to add this restriction - I've used get_r
Hi,
On 2022-11-21 14:21:35 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> >> To date testing database cluster wraparund was not easy as initdb has
> >> always
> >> inited it with default xid/mxid/mxoff. The option to specify any valid
> >> xid/mxid/mxoff at cluster startup will make these t
On Mon, Nov 21, 2022 at 1:12 PM Tom Lane wrote:
> Andres Freund writes:
> > On 2022-11-21 12:52:01 -0500, Robert Haas wrote:
> >> On Mon, Nov 21, 2022 at 12:35 PM Tom Lane wrote:
> >>> Why in the world is get_raw_page() marked as parallel safe?
> >>> It clearly isn't, given this restriction.
>
Andres Freund writes:
> On 2022-11-21 14:21:35 -0500, Tom Lane wrote:
>> pg_resetwal does seem like a better, more useful home for this; it'd
>> allow you to adjust these numbers after initial creation which might be
>> useful. I'm not sure how flexible it is right now in terms of where
>> you ca
Hi,
On 2022-11-21 15:12:15 -0500, Tom Lane wrote:
> If I were trying to find a better fix I'd be looking for ways for
> parallel workers to be able to read the parent's temp tables.
> (Perhaps that could tie in with the blue-sky discussion we had
> the other day about allowing autovacuum on temp t
Hi,
On 2022-11-21 15:16:46 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-11-21 14:21:35 -0500, Tom Lane wrote:
> >> pg_resetwal does seem like a better, more useful home for this; it'd
> >> allow you to adjust these numbers after initial creation which might be
> >> useful. I'm not
Andres Freund writes:
> On 2022-11-21 15:12:15 -0500, Tom Lane wrote:
>> If I were trying to find a better fix I'd be looking for ways for
>> parallel workers to be able to read the parent's temp tables.
>> (Perhaps that could tie in with the blue-sky discussion we had
>> the other day about allow
The CREATEROLE permission is in a very bad spot right now. The biggest
problem that I know about is that it allows you to trivially access
the OS user account under which PostgreSQL is running, which is
expected behavior for a superuser but simply wrong behavior for any
other user. This is because
Hi,
On 2022-11-20 19:02:12 -0700, David G. Johnston wrote:
> Both of these are written to the WAL, and a record is always written
> to the WAL as a self-contained unit, so the old record is full sized
> in the newly written WAL.
That's not really true. Normally the update record just logs the xma
Hi,
On 2022-11-21 00:16:20 -0800, sirisha chamarthi wrote:
> At present, calling pg_stat_reset* functions requires super user access
> unless explicitly grant execute permission on those. In this thread, I am
> proposing to grant execute on them to users with pg_monitor role
> permissions. This co
On Mon, Nov 21, 2022 at 3:45 PM Andres Freund wrote:
> On 2022-11-21 00:16:20 -0800, sirisha chamarthi wrote:
> > At present, calling pg_stat_reset* functions requires super user access
> > unless explicitly grant execute permission on those. In this thread, I am
> > proposing to grant execute on
On Mon, 2022-11-21 at 12:11 -0500, Tom Lane wrote:
> Robert Haas writes:
> > The reason that I pushed back -- not as successfully as I would have
> > liked -- on the changes to pg_stop_backup / pg_start_backup is that I
> > know there are people using the old method successfully, and it's not
> >
On Mon, Nov 21, 2022 at 4:34 PM Pavel Borisov wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: not tested
> Documentation:not tested
>
> I'
On 2022-11-20 Su 17:32, Thomas Munro wrote:
> On Sun, Nov 20, 2022 at 2:44 AM Andrew Dunstan wrote:
>> It might not suit your use case, but one of the things I do to reduce
>> fetch load is to run a local mirror which runs
>>
>>git fetch -q --prune
>>
>> every 5 minutes. It also runs a git d
Hi,
On 2022-11-21 15:47:12 +0300, Maxim Orlov wrote:
> After some investigation, I think, the problem is in the snapbuild.c
> (commit 272248a0c1b1, see [0]). We do allocate InitialRunningXacts
> array in the context of builder->context, but for the time when we call
> SnapBuildPurgeOlderTxn this c
1 - 100 of 165 matches
Mail list logo
