On Tue, Jun 21, 2022 at 6:49 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi David,
>
> > It's basically a glorified cross-reference. I didn't dislike directing
> the reader to the internals section enough to try and establish a better
> location for the main content.
>
> One
On 2022-06-21 Tu 17:25, Andres Freund wrote:
> Hi,
>
> On 2022-06-21 17:11:33 -0400, Andrew Dunstan wrote:
>> I and a couple of colleagues have looked it over. As far as it goes the
>> json fix looks kosher to me. I'll play with it some more.
> Cool.
>
> Any chance you could look at fixing the
Is it time yet to back-patch 2e517818f ("Fix SPI's handling of errors
during transaction commit")? We know we're going to have to do it
before Python 3.11 ships, and it's been stable in HEAD for 3.5 months
now. Also, the Fedora guys absorbed the patch a couple weeks ago [1]
because they're
On 2022-06-21 Tu 09:27, Jonathan S. Katz wrote:
> Hi,
>
> The RMT[1] with the release team has set a date of June 30, 2022 for
> the PostgreSQL 15 Beta 2 release. We encourage you to try to close as
> many open items[2] prior to the release.
>
> If you are working on patches for Beta 2, please
On Tue, Jun 21, 2022 at 6:33 AM Aleksander Alekseev <
aleksan...@timescale.com> wrote:
> Hi David,
>
> > Per discussion here:
> >
> >
> https://www.postgresql.org/message-id/163636931138.8076.5140809232053731248%40wrigleys.postgresql.org
> >
> > We can now easily document the array_length
Hi,
On 2022-06-21 17:11:33 -0400, Andrew Dunstan wrote:
> I and a couple of colleagues have looked it over. As far as it goes the
> json fix looks kosher to me. I'll play with it some more.
Cool.
Any chance you could look at fixing the "structure" of the generated
expression "program". The
> On 21 Jun 2022, at 16:59, Jakub Wartak wrote:
Oh, wow, your benchmarks show really impressive improvement.
> I think that 1 additional syscall is not going to be cheap just for
> non-standard OS configurations
Also we can reduce number of syscalls by something like
#if
>
> > On 21 Jun 2022, at 16:59, Jakub Wartak wrote:
> Oh, wow, your benchmarks show really impressive improvement.
>
FWIW I was trying to speedup long sequential file reads in Postgres using
fadvise hints. I've found no detectable improvements.
Then I've written 1Mb - 1Gb sequential read test
On 2022-06-17 Fr 16:06, Andres Freund wrote:
>
>
> I also attached my heavily-WIP patches for the ExprEvalStep issues,
Many thanks
> I
> accidentally had only included a small part of the contents of the json fix.
>
Yeah, that confused me mightily last week :-)
I and a couple of
On Tue, Jun 21, 2022 at 10:35:33AM +0900, Kyotaro Horiguchi wrote:
> At Mon, 20 Jun 2022 11:57:20 -0400, Robert Haas wrote
> in
>> says "don't keep trying to read more WAL, just promote RIGHT HERE?". I
>> think this logic would surely be incorrect in that case. It feels to
>> me like the right
On Wed, Jun 15, 2022 at 1:00 PM Amit Kapila wrote:
>
> On Wed, Jun 15, 2022 at 5:44 AM Zheng Li wrote:
> >
> >
> > While I agree that the deparser is needed to handle the potential
> > syntax differences between
> > the pub/sub, I think it's only relevant for the use cases where only a
> >
On Mon, Jun 20, 2022 at 09:03:23AM +0900, Michael Paquier wrote:
> On Thu, Jun 16, 2022 at 09:24:56AM +0200, Peter Eisentraut wrote:
>> I don't feel very strongly about this. It makes sense to stay consistent
>> with the existing COPY code.
>
> Yes, my previous argument is based on consistency
On Thu, Jun 16, 2022 at 6:07 AM Peter Smith wrote:
>
> Thank you for your review comments. Those reported mistakes are fixed
> in the attached patch v3.
>
This patch looks mostly good to me except for a few minor comments
which are mentioned below. It is not very clear in which branch(es) we
On Wed, Jun 22, 2022 at 4:24 PM Thomas Munro wrote:
> On Wed, Jun 22, 2022 at 2:54 PM Tom Lane wrote:
> > John Naylor writes:
> > > On Wed, Jun 1, 2022 at 2:57 AM Robert Haas wrote:
> > >> ... So we can fix this by:
> > >> 1. Using a relative pointer value other than 0 to represent a null
> >
Hi,
On 2022-06-21 17:22:05 +1200, Thomas Munro wrote:
> Problem: I saw 031_recovery_conflict.pl time out while waiting for a
> buffer pin conflict, but so far once only, on CI:
>
> https://cirrus-ci.com/task/5956804860444672
>
> timed out waiting for match: (?^:User was holding shared buffer
On Tue, Jun 21, 2022 at 05:36:35PM -0400, Andrew Dunstan wrote:
> Not quite sure why I'm listed against the OAT hook issue, all I did was
> commit a test that exposed the long existing problem :-)
Yes, we've discussed about this open and came to the conclusion that
assigning it to you is not
On Wed, Jun 22, 2022 at 2:54 PM Tom Lane wrote:
> John Naylor writes:
> > On Wed, Jun 1, 2022 at 2:57 AM Robert Haas wrote:
> >> ... So we can fix this by:
> >> 1. Using a relative pointer value other than 0 to represent a null
> >> pointer. Andres suggested (Size) -1.
> >> 2. Not storing the
Hi,
On Tue, Jun 21, 2022 at 08:04:01PM +, Imseih (AWS), Sami wrote:
>
> I separated the pg_stat_statements patch. The patch
> Introduces a secondary hash that tracks locations of
> A query ( by queryid ) in the external file.
I still think that's wrong.
> The hash
> remains in lockstep with
At Tue, 21 Jun 2022 12:49:24 +0200, Peter Eisentraut
wrote in
> I suggest that we add the gcc (also clang) option -ftabstop=4.
>
> This has two effects: First, it produces more accurate column numbers
> in compiler errors and correctly indents the code excerpts that the
> compiler shows with
> At Tue, 21 Jun 2022 12:49:24 +0200, Peter Eisentraut
> wrote in
>> One bit of trickery not addressed yet is that we might want to strip
>> out the option and not expose it through PGXS, since we don't know
>> what whitespacing rules external code uses.
This part seems like a bigger problem
On Tuesday, June 21, 2022 4:49 PM Amit Kapila
>
> On Tue, Jun 21, 2022 at 12:50 PM Amit Langote
> wrote:
> >
> > On Tue, Jun 21, 2022 at 3:35 PM houzj.f...@fujitsu.com
> > wrote:
> >
> > Attached a patch containing the above to consider as an alternative.
> >
>
> Thanks, the patch looks good
On Tue, Jun 21, 2022 at 11:02:57PM +1200, Thomas Munro wrote:
> On Tue, Jun 21, 2022 at 7:44 PM Michael Paquier wrote:
>> The extra business with QueryCancelHoldoffCount and DoingCommandRead
>> is the only addition for the snapshot, lock and tablespace conflict
>> handling part. I don't see why
On Thu, Jun 09, 2022 at 10:48:27AM +0900, Michael Paquier wrote:
> Three weeks later, ping. Robert, could you look at this thread?
And again. beta2 is planned to next week, and this is still an open
item. I could look at that by myself, but I always tend to get easily
confused with all the
On Wed, Jun 22, 2022 at 1:04 PM Michael Paquier wrote:
> With the patch, we should always have QueryCancelPending set to false,
> as long as there are no QueryCancelHoldoffCount. Perhaps an extra
> assertion for QueryCancelPending could be added at the beginning of
>
On Mon, Jun 13, 2022 at 10:25:24AM -0400, Robert Haas wrote:
> On Sun, Apr 17, 2022 at 11:22 PM Noah Misch wrote:
> > > Yes, but it could be false positives in some cases. For instance, the
> > > column {oid, bool, XLogRecPtr} should be okay on ALIGNOF_DOUBLE == 4
> > > and 8 platforms but the
On Wed, Jun 1, 2022 at 2:57 AM Robert Haas wrote:
> We do use fpm_segment_base(), but that accidentally fails
> to break, because instead of using relptr_access() it drills right
> through the abstraction and doesn't have any kind of special case for
> 0. So we can fix this by:
>
> 1. Using a
Hi,
On Wed, Jun 22, 2022 at 12:02 PM houzj.f...@fujitsu.com
wrote:
> Since the patch has been committed. Attach the last patch to fix the memory
> leak.
>
> The bug exists on PG10 ~ PG15(HEAD).
>
> For HEAD,PG14,PG13, to fix the memory leak, I think we should use
> free_attrmap instead of pfree
John Naylor writes:
> On Wed, Jun 1, 2022 at 2:57 AM Robert Haas wrote:
>> ... So we can fix this by:
>> 1. Using a relative pointer value other than 0 to represent a null
>> pointer. Andres suggested (Size) -1.
>> 2. Not storing the free page manager for the DSM in the main shared
>> memory
Hi,
Problem: Today when a data page is corrupted in the primary postgres with
physical replication (sync or async standbys), there seems to be no way to
repair it easily and we rely on PITR to recreate the postgres server or
drop the corrupted table (of course this is not an option for important
Przemysław Sztoch wrote on 14.06.2022 21:46:
Tom Lane wrote on 14.06.2022 15:43:
=?UTF-8?Q?Przemys=c5=82aw_Sztoch?= writes:
Please let me know what is the convention (procedure) of adding new
functions to pg_proc. Specifically how oid is allocated.
See
At Tue, 21 Jun 2022 14:59:07 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Tue, 21 Jun 2022 14:56:40 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > By the way, I noticed that "libpq_pipeline uniqviol" intermittently
> > fails for uncertain reasons.
> >
> > > result 574/575: pipeline aborted
>
Hi hackers!
Recently we faced a problem with one of our production clusters. We use a
cascade replication setup in this cluster, that is: master, standby (r1),
and cascade standby (r2). From time to time, the replication lag on r1 used
to grow, while on r2 it did not. Analysys showed that r1
On Tuesday, June 21, 2022 3:21 PM Amit Langote wrote:
>
> On Tue, Jun 21, 2022 at 3:35 PM houzj.f...@fujitsu.com
> wrote:
> > On Tuesday, June 21, 2022 1:29 PM Amit Kapila :
> > > After pushing this patch, buildfarm member prion has failed.
> > >
>
On Tue, Jun 21, 2022 at 12:50 PM Amit Langote wrote:
>
> On Tue, Jun 21, 2022 at 3:35 PM houzj.f...@fujitsu.com
> wrote:
>
> Attached a patch containing the above to consider as an alternative.
>
Thanks, the patch looks good to me. I'll push this after doing some testing.
--
With Regards,
On Tuesday, June 21, 2022 1:29 PM Amit Kapila :
>
> On Tue, Jun 21, 2022 at 8:02 AM Amit Kapila wrote:
> >
> > On Tue, Jun 21, 2022 at 7:49 AM Amit Langote
> wrote:
> > >
> > >
> > > I think it should spell out REPLICA IDENTITY explicitly to avoid the
> > > commit being confused to have to do
At Tue, 21 Jun 2022 14:56:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> By the way, I noticed that "libpq_pipeline uniqviol" intermittently
> fails for uncertain reasons.
>
> > result 574/575: pipeline aborted
> > ...
> > done writing
> >
On Tue, Jun 21, 2022 at 3:35 PM houzj.f...@fujitsu.com
wrote:
> On Tuesday, June 21, 2022 1:29 PM Amit Kapila :
> > After pushing this patch, buildfarm member prion has failed.
> > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=prion=HE
> > AD
> >
> > It seems to me that the problem
On Tue, Jun 21, 2022 at 05:22:05PM +1200, Thomas Munro wrote:
> Here's one thing I got a bit confused about along the way, but it
> seems the comment was just wrong:
>
> + /*
> +* If we can abort just the current
> subtransaction then we are OK
> +
On Tuesday, June 21, 2022 4:49 PM Amit Kapila wrote:
>
> On Tue, Jun 21, 2022 at 12:50 PM Amit Langote
> wrote:
> >
> > On Tue, Jun 21, 2022 at 3:35 PM houzj.f...@fujitsu.com
> > wrote:
> >
> > Attached a patch containing the above to consider as an alternative.
> >
>
> Thanks, the patch
On Tue, Jun 21, 2022 at 5:08 PM houzj.f...@fujitsu.com
wrote:
> On Tuesday, June 21, 2022 3:21 PM Amit Langote
> wrote:
> > Thanks for the patch.
> >
> > I agree it's an old bug. A partition map entry's localrel may point
> > to a stale Relation pointer, because once the caller had closed the
On Wed, Nov 18, 2020 at 1:44 PM Magnus Hagander wrote:
> On Wed, Nov 18, 2020 at 1:31 PM Alvaro Herrera
> wrote:
> >
> > On 2020-Nov-18, Magnus Hagander wrote:
> >
> > > It would be trivial to change this so that it only actually updates
> > > pages if they have been changed.
> >
> > I think
>> > On 21 Jun 2022, at 12:35, Amit Kapila wrote:
>> >
>> > I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can
>> > help your case?
>>
>> AFAICS recovery_prefetch tries to prefetch main fork, but does not try to
>> prefetch WAL itself before reading it. Kirill is trying to
> > Maybe the important question is why would be readahead mechanism be
> disabled in the first place via /sys | blockdev ?
>
> Because database should know better than OS which data needs to be
> prefetched and which should not. Big OS readahead affects index scan
> performance.
OK fair point,
On Tue, Jun 21, 2022 at 10:33 PM Jakub Wartak wrote:
> > > Maybe the important question is why would be readahead mechanism be
> > disabled in the first place via /sys | blockdev ?
> >
> > Because database should know better than OS which data needs to be
> > prefetched and which should not. Big
On Tue, Jun 21, 2022 at 3:18 PM Andrey Borodin wrote:
>
> > On 21 Jun 2022, at 12:35, Amit Kapila wrote:
> >
> > I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can
> > help your case?
>
> AFAICS recovery_prefetch tries to prefetch main fork, but does not try to
> prefetch
On Tue, Jun 21, 2022 at 1:07 PM Kirill Reshke wrote:
>
> Recently we faced a problem with one of our production clusters. We use a
> cascade replication setup in this cluster, that is: master, standby (r1), and
> cascade standby (r2). From time to time, the replication lag on r1 used to
>
On Mon, Jun 20, 2022 at 8:35 PM Aleksander Alekseev
wrote:
>
> I would like to invest some time into providing a corresponding patch
> for the core and implementing "pg_copy_parquet" extension as a
> practical example, and yet another, a bit simpler, extension as an API
> usage example for the
Hi Ashutosh,
> An extension just for COPY to/from parquet looks limited in
> functionality. Shouldn't this be viewed as an FDW or Table AM support
> for parquet or other formats? Of course the later is much larger in
> scope compared to the first one. But there may already be efforts
> underway
>
I suggest that we add the gcc (also clang) option -ftabstop=4.
This has two effects: First, it produces more accurate column numbers
in compiler errors and correctly indents the code excerpts that the
compiler shows with those. Second, it enables the compiler's detection
of confusingly
On Tue, Jun 21, 2022 at 4:22 PM Thomas Munro wrote:
>
> On Tue, Jun 21, 2022 at 10:33 PM Jakub Wartak wrote:
> > > > Maybe the important question is why would be readahead mechanism be
> > > disabled in the first place via /sys | blockdev ?
> > >
> > > Because database should know better than OS
On Tue, Jun 21, 2022 at 7:44 PM Michael Paquier wrote:
> The extra business with QueryCancelHoldoffCount and DoingCommandRead
> is the only addition for the snapshot, lock and tablespace conflict
> handling part. I don't see why a reason why that could be wrong on a
> close lookup. Anyway, why
> On 21 Jun 2022, at 12:35, Amit Kapila wrote:
>
> I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can
> help your case?
AFAICS recovery_prefetch tries to prefetch main fork, but does not try to
prefetch WAL itself before reading it. Kirill is trying to solve the problem
> On 21 Jun 2022, at 13:20, Jakub Wartak wrote:
>
> Maybe the important question is why would be readahead mechanism be disabled
> in the first place via /sys | blockdev ?
Because database should know better than OS which data needs to be prefetched
and which should not. Big OS readahead
Hi David,
> Per discussion here:
>
> https://www.postgresql.org/message-id/163636931138.8076.5140809232053731248%40wrigleys.postgresql.org
>
> We can now easily document the array_length behavior of returning null
> instead of zero for an empty array/dimension.
>
> I added an example to the
Michael Paquier wrote on 21.06.2022 02:11:
On Mon, Jun 20, 2022 at 10:37:57AM +0200, Przemysław Sztoch wrote:
But ligature check is performed on combining_ids (result of translation),
not on base codepoint.
Without it, you will get assertions in get_plain_letters.
Hmm. I am wondering if we
Thomas Munro wrote on 21.06.2022 02:53:
On Tue, Jun 21, 2022 at 12:11 PM Michael Paquier wrote:
Yeah, Latin-ASCII.xml is getting it wrong here, then. unaccent
fetches the thing from this URL currently:
Hi David,
> It's basically a glorified cross-reference. I didn't dislike directing the
> reader to the internals section enough to try and establish a better location
> for the main content.
One problem I see is that:
+ [..], but as there is no pre-existing data, visibility checks are
> On Tue, Jun 21, 2022 at 10:33 PM Jakub Wartak
> wrote:
> > > > Maybe the important question is why would be readahead mechanism
> > > > be
> > > disabled in the first place via /sys | blockdev ?
> > >
> > > Because database should know better than OS which data needs to be
> > > prefetched and
On Tue, Jun 21, 2022 at 4:55 PM Amit Kapila wrote:
>
> On Tue, Jun 21, 2022 at 3:18 PM Andrey Borodin wrote:
> >
> > > On 21 Jun 2022, at 12:35, Amit Kapila wrote:
> > >
> > > I wonder if the newly introduced "recovery_prefetch" [1] for PG-15 can
> > > help your case?
> >
> > AFAICS
Hi Jelte,
> Load balancing connections across multiple read replicas is a pretty
> common way of scaling out read queries. There are two main ways of doing
> so, both with their own advantages and disadvantages:
> 1. Load balancing at the client level
> 2. Load balancing by connecting to an
On Tue, Jun 21, 2022 at 5:41 PM Bharath Rupireddy
wrote:
>
> On Tue, Jun 21, 2022 at 4:55 PM Amit Kapila wrote:
> >
> > On Tue, Jun 21, 2022 at 3:18 PM Andrey Borodin wrote:
> > >
> > > > On 21 Jun 2022, at 12:35, Amit Kapila wrote:
> > > >
> > > > I wonder if the newly introduced
Hi,
The RMT[1] with the release team has set a date of June 30, 2022 for the
PostgreSQL 15 Beta 2 release. We encourage you to try to close as many
open items[2] prior to the release.
If you are working on patches for Beta 2, please be sure that they are
committed no later than June 26,
62 matches
Mail list logo
