Hi,
On November 19, 2021 12:31:00 PM PST, Tom Lane wrote:
>Virender Singla writes:
>> Why do Toast tables have it's own visibility map and xmin, xmax columns etc?
>> Isn't it increasing row size in a toast table and adding more complexity?
Given the size of toasted data, the overhead is
On Fri, Nov 19, 2021 at 7:41 PM Masahiko Sawada wrote:
>
> On Thu, Nov 18, 2021 at 12:26 PM Amit Kapila wrote:
> >
> > On Wed, Nov 17, 2021 at 7:12 PM osumi.takami...@fujitsu.com
> > wrote:
> > >
> > > On Wednesday, November 17, 2021 10:00 PM Amit Kapila
> > > wrote:
> > > >
> > > > Can you
On Fri, Nov 19, 2021 at 4:07 PM vignesh C wrote:
> The Attached v15 patch has the fixes for the same.
Thanks. The v15 patch LGTM and the cf bot is happy hence marking it as RfC.
Regards,
Bharath Rupireddy.
On Sat, Nov 20, 2021 at 11:10 AM Michael Paquier wrote:
> What you should do is to set such a flag in the signal handler, and
> then check its value in the main loop of pg_waldump, dumping the stats
> if it is detected as turned on because of a signal.
Thanks. Here's the v3 patch, a much simpler
I wrote:
> snapper just exhibited the same failure, too:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper=2021-11-18%2016%3A09%3A49
I grepped the buildfarm logs for all recent (last 3 months) occurrences of
'could not read two-phase state'. Here's the results:
sysname |
On Fri, Nov 19, 2021 at 11:45:40PM +, Bossart, Nathan wrote:
> +1 to something like "wal replay" or "wal apply." My view is that
> terms like "startup" and "recovery" indicate the goal of the process
> while "replay" and "apply" just explain what it does. This would be
> in line with the
On Sat, Nov 20, 2021 at 12:17:53AM +, Bossart, Nathan wrote:
> I bet it's possible to use the ClientAuthentication_hook for this. In
> any case, I agree that it probably belongs server-side so that other
> clients can benefit from this.
ClientAuthentication_hook is called before the user is
On Sat, Nov 20, 2021 at 10:03:27AM +0530, Bharath Rupireddy wrote:
> Here's the v2 patch with the above changes i.e. pg_waldump now eimits
> the computed stats at the time of termination. Please review it.
+#define MAX_XLINFO_TYPES 16
+#define fatal_error(...) do { pg_log_fatal(__VA_ARGS__);
Noah Misch writes:
> Tom Turelinckx, are you able to provide remote access to kittiwake or
> tadarida? I'd use it to attempt the above things. All else being equal,
> kittiwake is more relevant since it's still supported upstream.
snapper just exhibited the same failure, too:
On Wed, Nov 17, 2021 at 11:05:06PM -0800, Noah Misch wrote:
> On Wed, Nov 17, 2021 at 05:47:10PM -0500, Tom Lane wrote:
> > Noah Misch writes:
> > > Each of the three failures happened on a sparc64 Debian+gcc machine. I
> > > had
> > > tried ~8000 iterations on thorntail, another sparc64
On Thu, Nov 18, 2021 at 2:03 PM Bharath Rupireddy
wrote:
>
> On Thu, Nov 18, 2021 at 1:51 PM Michael Paquier wrote:
> >
> > On Thu, Nov 18, 2021 at 01:32:08PM +0530, Bharath Rupireddy wrote:
> > > Hm. So, the pg_waldump can have handlers for SIGINT, SIGTERM, SIGQUIT
> > > and then it should emit
> On Nov 19, 2021, at 7:25 AM, Mark Dilger wrote:
>
> Jeff Davis and I had a long conversation off-list yesterday and reached the
> same conclusion. I will be submitting a version of 0003 which does not
> depend on the prior two patches.
Renamed as 0001 in version 3, as it is the only
On 11/17/21, 11:39 PM, "Bharath Rupireddy"
wrote:
> Please review the attached v2.
LGTM. I've marked this one as ready-for-committer.
Nathan
On 11/19/21, 7:56 AM, "Tom Lane" wrote:
> That leads me to wonder about server-side solutions. It's easy
> enough for the server to see that it's used a password with an
> expiration N days away, but how could that be reported to the
> client? The only idea that comes to mind that doesn't seem
On 11/18/21, 12:24 PM, "Tom Lane" wrote:
> Alvaro Herrera writes:
>> If we change the name, and I support the idea that we do, I think a
>> good name would be "wal replay". I think "recovery" is not great
>> precisely because in a standby there is likely no crash that we're
>> recovering from.
Hi,
On 2021-11-19 17:17:44 -0500, Melanie Plageman wrote:
> For the README, I found the instructions very clear. My only concern is
> that the cirrus-ci UI will change and the instructions on how to enable
> cirrus-ci on a repository will not be accessible in the same way in the
> future.
I
On Fri, Nov 19, 2021 at 10:20 AM Andres Freund wrote:
> You can't just skip doing updates without causing problems.
>
>
Given you can do exactly this by using a trigger this statement is either
false or I'm missing some piece of knowledge it relies upon.
David J.
On Sat, Nov 20, 2021 at 11:17 AM Melanie Plageman
wrote:
> - do you not need to change the default core resource limits for
> FreeBSD?
Unfortunately the performance really sucks on that FreeBSD CI system
if you crank it up, and I haven't had time to figure out why yet :-/
Possibly something to
Hi,
I reviewed the first patch in this set
(v2-0001-ci-Add-CI-for-FreeBSD-Linux-MacOS-and-Windows-uti.patch).
For the README, I found the instructions very clear. My only concern is
that the cirrus-ci UI will change and the instructions on how to enable
cirrus-ci on a repository will not be
On Sat, Nov 20, 2021 at 9:34 AM Tom Lane wrote:
> Thomas Munro writes:
> > This has been fixed. So now there are working basic futexes on Linux,
> > macOS, {Free,Open,Net,Dragonfly}BSD (though capabilities beyond basic
> > wait/wake vary, as do APIs). So the question is whether it would be
> >
Thomas Munro writes:
> This has been fixed. So now there are working basic futexes on Linux,
> macOS, {Free,Open,Net,Dragonfly}BSD (though capabilities beyond basic
> wait/wake vary, as do APIs). So the question is whether it would be
> worth trying to do our own futex-based semaphores, as
Virender Singla writes:
> Why do Toast tables have it's own visibility map and xmin, xmax columns etc?
> Isn't it increasing row size in a toast table and adding more complexity?
There are advantages to having the same low-level format for toast tables
as regular tables --- for example, that you
On Fri, Oct 29, 2021 at 4:54 PM Thomas Munro wrote:
> On Sun, Oct 24, 2021 at 10:50 PM Thomas Munro wrote:
> > Sadly, although the attached proof-of-concept patch allows a
> > PREFERRED_SEMAPHORES=FUTEX build to pass tests on macOS (which also
> > lacks native unnamed semas), FreeBSD and Linux
On Mon, May 3, 2021 at 5:24 PM Melanie Plageman
wrote:
>
> So, I've written a patch which avoids doing the immediate fsync for
> index builds either by using shared buffers or by queueing sync requests
> for the checkpointer. If a checkpoint starts during the index build and
> the backend is not
Another point that currently manual VACUUM job does cleanup/freeze on
primary table first and then toast table. It looks easy pick to possibly
have a configurable parameter to run it on both the tables in parallel.
On Sat, Nov 20, 2021 at 12:15 AM Virender Singla
wrote:
> Why do Toast tables
>
> I suppose if the application side cannot be trusted to code to a
> specification without having the server side add validation and/or
> compensation code to catch the bugs then, yes, one option is to have the
> server side do extra work. There are other solutions, some of which are
> not even
On 2021-Nov-18, Robert Haas wrote:
> On Thu, Nov 18, 2021 at 2:21 PM Alvaro Herrera
> wrote:
> > Would it work to start postmaster directly instad of using pg_ctl, and
> > then rely on (say) pg_isready?
>
> I *think* that pg_isready would also fail, because the documentation
> says "pg_isready
On 2021-Nov-17, Peter Geoghegan wrote:
> Commit 2fd8685e7f simplified the checking of modified attributes that
> takes place within heap_update(). This included a micro-optimization
> that affects pages marked PageIsFull(): when the target page is marked
> with PD_PAGE_FULL (which must have been
Why do Toast tables have it's own visibility map and xmin, xmax columns etc?
Isn't it increasing row size in a toast table and adding more complexity?
Ideally all the vacuum cleanup on a TOAST can be done based on Primary
table xmin,xmax and VM info. Yes, that makes any cleanup on TOAST to be
On Fri, Nov 19, 2021 at 10:57 AM Marcos Pegoraro wrote:
> So, Postgres guys will have to review all code being done on apps ?
>>
>
>
I suppose if the application side cannot be trusted to code to a
specification without having the server side add validation and/or
compensation code to catch the
On 11/19/21 18:50, Tom Lane wrote:
Tomas Vondra writes:
While working on a patch, I noticed that we never clean the cache of
sequence values, i.e. seqhashtab in sequence.c. That is, once we create
an entry for a sequence (by calling nextval), it will stay forever
(until the backend
>
> I get the idea of letting the server centralize logic like this - but
> frankly if the application is choosing to send all that data across the
> wire just to have the server throw it away the application is wasting
> network I/O. If it does manage its resources carefully then the server
>
Tomas Vondra writes:
> While working on a patch, I noticed that we never clean the cache of
> sequence values, i.e. seqhashtab in sequence.c. That is, once we create
> an entry for a sequence (by calling nextval), it will stay forever
> (until the backend terminates). Even if the sequence gets
On Fri, Nov 19, 2021 at 10:03 AM Marcos Pegoraro wrote:
> Because it takes resources to determine that nothing changed. If you want
>> to opt-in into that there is even an extension trigger that makes doing so
>> fairly simple. But it's off by default because the typical case is that
>> people
Hi,
While working on a patch, I noticed that we never clean the cache of
sequence values, i.e. seqhashtab in sequence.c. That is, once we create
an entry for a sequence (by calling nextval), it will stay forever
(until the backend terminates). Even if the sequence gets dropped, the
entry
Marcos Pegoraro writes:
> But it takes resources for other operations, right ?
> I think this is not unusual. If an user double click on a grid, just sees a
> record and clicks ok to save, probably that application calls an update
> instead of seeing if some field were changed before that.
[
Hi,
On November 19, 2021 8:38:25 AM PST, Marcos Pegoraro wrote:
>Why this happens ?
>
>create table t(i int);
>CREATE TABLE
>insert into t values(1);
>INSERT 0 1
>select (ctid::text::point)[1]::int, * from t;
> ctid | i
>--+---
>1 | 1
>(1 row)
>update t set i = i;
>UPDATE 1
>select
"Bossart, Nathan" writes:
> Okay, here is an attempt at adding control-C support for \prompt and
> \connect. It was reasonably straightforward. I did have to teach
> simple_prompt_extended() to add a newline after a cancellation when
> "echo" is true.
LGTM, pushed after very minor fooling with
>
> Because it takes resources to determine that nothing changed. If you want
> to opt-in into that there is even an extension trigger that makes doing so
> fairly simple. But it's off by default because the typical case is that
> people don't frequently perform no-op updates so why eat the
Le 19/11/2021 à 16:55, Tom Lane a écrit :
Gilles Darold writes:
Now that the security policy is getting stronger, it is not uncommon to
create users with a password expiration date (VALID UNTIL).
TBH, I thought people were starting to realize that forced password
rotations are a net security
Hi,
On 2021-11-02 15:26:52 -0400, Melanie Plageman wrote:
> Subject: [PATCH v14 1/4] Allow bootstrap process to beinit
Pushed.
> +/*
> + * On modern systems this is really just *counter++. On some older systems
> + * there might be more to it, due to inability to read and write 64 bit
>
On Fri, Nov 19, 2021 at 9:38 AM Marcos Pegoraro wrote:
> If nothing was changed, why create a new record, append data to wal, set
> old record as deleted, etc, etc ?
>
Because it takes resources to determine that nothing changed. If you want
to opt-in into that there is even an extension
On Fri, Nov 19, 2021 at 9:14 PM Fujii Masao wrote:
> On 2021/11/19 22:13, Bharath Rupireddy wrote:
> > How about adding the warning message in pgfdw_abort_cleanup instead of
> > pgfdw_get_cleanup_result?
> >
> > Just before this in pgfdw_abort_cleanup seems better to me.
>
> I was thinking
Why this happens ?
create table t(i int);
CREATE TABLE
insert into t values(1);
INSERT 0 1
select (ctid::text::point)[1]::int, * from t;
ctid | i
--+---
1 | 1
(1 row)
update t set i = i;
UPDATE 1
select (ctid::text::point)[1]::int, * from t;
ctid | i
--+---
2 | 1
(1 row)
If
On Fri, Nov 19, 2021 at 1:13 PM Richard Guo wrote:
>
> Happened to notice this when reading around the codes. The BrinMemTuple
> would be initialized in brin_new_memtuple(), right after being created.
> So we don't need to initialize it again outside.
>
> diff --git
On Fri, Nov 19, 2021 at 8:48 PM Fujii Masao wrote:
>
> On 2021/11/19 21:57, Bharath Rupireddy wrote:
> >> If this is a bug, IMO the following change needs to be applied. Thought?
> >>
> >> ---
> >> ereport(elevel,
> >>
> On Nov 19, 2021, at 2:23 AM, Amit Kapila wrote:
>
> I was thinking why not separate the ownership and "run as" privileges
> for the subscriptions? We can introduce a new syntax in addition to
> the current syntax for "Owner" for this as:
>
> Create Subscription sub RUNAS ...;
> Alter
Gilles Darold writes:
> Now that the security policy is getting stronger, it is not uncommon to
> create users with a password expiration date (VALID UNTIL).
TBH, I thought people were starting to realize that forced password
rotations are a net security negative. It's true that a lot of
> On Nov 19, 2021, at 1:56 AM, Amit Kapila wrote:
>
> How about allowing to change ownership only for disabled
> subscriptions? Basically, users need to first disable the subscription
> and then change its ownership.
There are some open issues about non-superuser owners that Jeff would like
On 2021/11/19 22:13, Bharath Rupireddy wrote:
How about adding the warning message in pgfdw_abort_cleanup instead of
pgfdw_get_cleanup_result?
Just before this in pgfdw_abort_cleanup seems better to me.
I was thinking pgfdw_get_cleanup_result() is better because it can
easily report
> On Nov 19, 2021, at 1:44 AM, Amit Kapila wrote:
>
> I think we are saying the same thing. I intend to say that your 0003*
> patch closes the current gap in the code and we should consider
> applying it irrespective of what we do with respect to changing the
> ... OWNER TO .. behavior. Is
On Thu, Nov 18, 2021 at 4:49 PM Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Nov 18, 2021 at 3:14 PM Tom Lane wrote:
> >> I'm a little dubious that this test case is valuable enough to
> >> mess around with a nonstandard postmaster startup protocol, though.
>
> > The problem that I have
On Fri, Nov 19, 2021 at 5:17 AM Peter Eisentraut
wrote:
> If people want to do that kind of thing (I'm undecided whether the
> complexity is worth it), then make it a different API. The pg_log_*
> calls are for writing formatted output. They normalized existing
> hand-coded patterns at the
On 2021/11/19 16:54, Michael Paquier wrote:
On Thu, Nov 18, 2021 at 10:04:57AM +0530, Bharath Rupireddy wrote:
Yeah let's not do that. I'm fine with the
wait_event_for_archive_command_v2.patch as is.
Switched the patch as RfC, then.
Thanks! Barring any objection, I will commit the patch.
On 2021/11/19 21:57, Bharath Rupireddy wrote:
If this is a bug, IMO the following change needs to be applied. Thought?
---
ereport(elevel,
(errcode(sqlstate),
-message_primary ?
On Fri, 19 Nov 2021 at 20:19, Gilles Darold wrote:
> Hi all,
>
>
> Now that the security policy is getting stronger, it is not uncommon to
> create users with a password expiration date (VALID UNTIL). The problem
> is that the user is only aware that his password has expired when he can no
>
Peter Eisentraut writes:
>> On Wed, Oct 13, 2021 at 12:50:38PM -0400, Robert Haas wrote:
>>> Would it be reasonable to consider something similar for the control
>>> file, for the benefit of distributions that are not the same on disk?
> The catalog version already serves this purpose.
We
Hi all,
Now that the security policy is getting stronger, it is not uncommon to
create users with a password expiration date (VALID UNTIL). The problem
is that the user is only aware that his password has expired when he can
no longer log in unless the application with which he is connecting
On Thu, Nov 18, 2021 at 12:26 PM Amit Kapila wrote:
>
> On Wed, Nov 17, 2021 at 7:12 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > On Wednesday, November 17, 2021 10:00 PM Amit Kapila
> > wrote:
> > >
> > > Can you please tell us why you think the names in your proposed patch are
> > >
On Sat, Nov 13, 2021 at 5:43 AM Tom Lane wrote:
> Amit Langote writes:
> > On Fri, Nov 12, 2021 at 8:19 AM Tom Lane wrote:
> >> Anyway, I think that (1) we should write some more test cases around
> >> this behavior, (2) you need to establish the snapshot to use in two
> >> different ways for
On Fri, Nov 19, 2021 at 7:09 PM Amit Kapila wrote:
>
> On Fri, Nov 19, 2021 at 3:00 PM Greg Nancarrow wrote:
> >
> > On Fri, Nov 19, 2021 at 8:15 PM Amit Kapila wrote:
> > > Yeah in such a case last_error_time can be shown as a time before
> > > first_error_time but I don't think that will be a
On Fri, Nov 19, 2021 at 3:31 PM Fujii Masao wrote:
>
> Hi,
>
> postgres_fdw reports no log message when it sends "ABORT TRANSACTION" etc
> and gives up getting a reply from a foreign server because of timeout or
> connection trouble. This makes the troubleshooting a bit harder when
> using
On Fri, Nov 19, 2021 at 1:48 PM Fujii Masao wrote:
>
> Hi,
>
> pgfdw_report_error() in postgres_fdw is implemented to report the message
> "could not obtain ..." if message_primary is NULL as follows.
> But, just before this ereport(), message_primary is set to
> pchomp(PQerrorMessage()) if it's
Patch in the previous letter is full of faulties. Please, use new version.
Also, here we fixed the problem with loosing CSN value in a parallel
worker (TAP test 003_parallel_safe.pl). Thanks for a.pyhalov for the
problem detection and a bugfix.
--
regards,
Andrey Lepikhov
Postgres
On Thu, Nov 18, 2021 at 9:52 PM Justin Pryzby wrote:
>
> On Wed, Nov 17, 2021 at 08:12:44PM +0530, vignesh C wrote:
> > Attached v14 patch has the fixes for the same.
>
> Thanks for updating the patch.
>
> I cleaned up the docs and comments. I think this could be nearly "Ready".
>
> If you like
On Fri, Nov 19, 2021 at 12:00 AM Jeff Davis wrote:
>
> On Wed, 2021-11-17 at 16:17 -0800, Mark Dilger wrote:
> > You must choose a single role you want the subscription to run
> > under.
>
> I think that was the source of a lot of my confusion:
>
> Your patches are creating the notion of a "run
On 16.11.21 16:18, Robert Haas wrote:
I think we need frontend facilities that look like the backend
facilities, so try/catch blocks, on-exit callbacks, and whatever else
there is. Otherwise code reuse is going to continue to be annoying.
If people want to do that kind of thing (I'm undecided
On 09.11.21 21:20, Tom Lane wrote:
Why is this different from the half-dozen
other fsync-error cases in the same file? Why, if fsync failure
here is so catastrophic, is it okay to just return a normal failure
code when tar_close doesn't even get to this point because of some
earlier error? At
On Fri, Nov 19, 2021 at 3:00 PM Greg Nancarrow wrote:
>
> On Fri, Nov 19, 2021 at 8:15 PM Amit Kapila wrote:
> > Yeah in such a case last_error_time can be shown as a time before
> > first_error_time but I don't think that will be a big problem, the
> > next message will fix it. I don't see what
‐‐‐ Original Message ‐‐‐
On Friday, November 19th, 2021 at 3:07 AM, Michael Paquier
wrote:
> On Thu, Nov 18, 2021 at 07:54:37PM +0530, Jeevan Ladhe wrote:
>
> > In dir_open_for_write() I observe that we are writing the header
> > and then calling LZ4F_compressEnd() in case there is an
Hi,
postgres_fdw reports no log message when it sends "ABORT TRANSACTION" etc
and gives up getting a reply from a foreign server because of timeout or
connection trouble. This makes the troubleshooting a bit harder when
using postgres_fdw.
So how about making postgres_fdw report a warning in
On 19.11.21 08:58, Michael Paquier wrote:
On Wed, Oct 13, 2021 at 12:50:38PM -0400, Robert Haas wrote:
I'm not a different vendor, but I do work on different code than you
do, and I like this. Advanced Server accidentally dodges this problem
at present by shipping with a different FUNC_MAX_ARGS
On Thu, Nov 18, 2021 at 9:15 PM Mark Dilger
wrote:
>
> The prior version of the patch only picked up the change if it happened to
> start a new worker, but could process multiple transactions without noticing
> the change. Now, it is limited to finishing the current transaction. Would
> you
On Thu, Nov 18, 2021 at 9:03 PM Mark Dilger
wrote:
>
> > On Nov 18, 2021, at 2:50 AM, Amit Kapila wrote:
> >
> >> I gave that a slight amount of thought during the design of this patch,
> >> but didn't think we could refuse to revoke superuser on such a basis, and
> >> didn't see what we
On Fri, Nov 19, 2021 at 8:15 PM Amit Kapila wrote:
> Yeah in such a case last_error_time can be shown as a time before
> first_error_time but I don't think that will be a big problem, the
> next message will fix it. I don't see what we can do about it and the
> same is true for other cases like
On Fri, Nov 19, 2021 at 1:22 PM Greg Nancarrow wrote:
>
> On Fri, Nov 19, 2021 at 5:52 PM Amit Kapila wrote:
> > Why that Assert will hit? We seem to be always passing 'create' as
> > true so it should create a new entry. I think a similar situation can
> > happen for functions and it will be
Hi Daniel,
Thanks for checking in on this patch.
Attached rebased version.
Regards,
Soumyadeep (VMware)
From 51149e4f877dc2f8bf47a1356fc8b0ec2512ac6d Mon Sep 17 00:00:00 2001
From: Soumyadeep Chakraborty
Date: Fri, 19 Nov 2021 00:33:17 -0800
Subject: [PATCH v4 1/1] Introduce feature to start
On 2021-11-18 21:43, kuroda.hay...@fujitsu.com wrote:
Dear Kato-san,
Thank you for your interest!
> I also want you to review the postgres_fdw part,
> but I think it should not be attached because cfbot cannot understand
> such a dependency
> and will throw build error. Do you know how to
Hi,
pgfdw_report_error() in postgres_fdw is implemented to report the message
"could not obtain ..." if message_primary is NULL as follows.
But, just before this ereport(), message_primary is set to
pchomp(PQerrorMessage()) if it's NULL. So ISTM that message_primary is
always not NULL in
79 matches
Mail list logo
