On Wed, Jun 03, 2020 at 12:08:56PM -0300, Euler Taveira wrote:
> Consistency is a good goal. Why don't we clear the relreplident from the
> relation while dropping the index? relation_mark_replica_identity() already
> does that but do other things too. Let's move the first code block from
> relatio
Hi
plpgsql_check extension is almost complete now. This extension is available
on all environments and for all supported Postgres releases. It is probably
too big to be part of contrib, but I think so it can be referenced in
https://www.postgresql.org/docs/current/plpgsql-development-tips.html
cha
Hi
I am working on tracing support to plpgsql_check
https://github.com/okbob/plpgsql_check
I would like to print content of variables - and now, I have to go some
deeper than I would like. I need to separate between scalar, row, and
record variables. PLpgSQL has code for it - but it is private.
I'm sorry for the late reply.
> This version seems to fail under Werror which is used in the Travis builds:
>
> autovacuum.c: In function ‘relation_needs_vacanalyze’:
> autovacuum.c:3117:59: error: ‘reltuples’ may be used uninitialized in this
> function [-Werror=maybe-uninitialized]
>anlthre
On Sat, 15 Aug 2020 at 12:19, Amit Kapila wrote:
>
> On Fri, Aug 14, 2020 at 4:06 PM Amit Kapila wrote:
> >
> > On Mon, Aug 10, 2020 at 10:24 AM Masahiko Sawada
> > wrote:
> > >
> > > It's true that heap_page_is_all_visible() is called from only
> > > lazy_vacuum_page() but I'm concerned it woul
Hello Masahiko-san,
Thanks for the review. Please check the comments inline below:
On Fri, Aug 14, 2020 at 10:07 AM Masahiko Sawada
wrote:
> Thank you for updating the patch! Here are my comments on v5 patch:
>
> --- a/contrib/Makefile
> +++ b/contrib/Makefile
> @@ -35,6 +35,7 @@ SUBDIRS = \
>
On Mon, 17 Aug 2020 at 10:32, Michael Paquier wrote:
>
> On Fri, Aug 14, 2020 at 05:15:20PM +0900, Michael Paquier wrote:
> > Good catch it is. Your phrasing looks good to me.
>
> Fixed as b4f1639. Thanks.
Thank you!
Regards,
--
Masahiko Sawadahttp://www.2ndQuadrant.com/
PostgreS
On Sun, Aug 09, 2020 at 12:33:43PM -0400, Tom Lane wrote:
> I don't see how psql could obtain a "real" list of foreign schemas
> from an arbitrary FDW, even if it magically knew which server the
> user would specify later in the command. So this behavior seems fine.
> It has some usefulness, while
On Thu, Jul 30, 2020 at 11:29 PM Robert Haas wrote:
>
> On Mon, Jul 27, 2020 at 1:02 PM Mark Dilger
> wrote:
> > Not at all! I appreciate all the reviews.
>
> Reviewing 0002, reading through verify_heapam.c:
>
> +typedef enum SkipPages
> +{
> + SKIP_ALL_FROZEN_PAGES,
> + SKIP_ALL_VISIBLE_PAGES,
Hi Vignesh,
Some further comments:
(1) v3-0002-Framework-for-leader-worker-in-parallel-copy.patch
+/*
+ * Each worker will be allocated WORKER_CHUNK_COUNT of records from DSM data
+ * block to process to avoid lock contention. This value should be divisible by
+ * RINGSIZE, as wrap around cases
On Fri, May 29, 2020 at 12:16:47AM +0200, Daniel Gustafsson wrote:
> SSL_CTX_load_verify_locations and X509_STORE_load_locations are deprecated and
> replaced by individual calls to load files and directories. These are quite
> straightforward, and are implemented like how we handle the TLS protoc
On Mon, Aug 17, 2020 at 1:27 PM Thomas Munro wrote:
>
> On Mon, Aug 17, 2020 at 1:20 PM Tom Lane wrote:
> > Thomas Munro writes:
> > > I wonder what caused this[1] one-off failure to see tuples in clustered
> > > order:
> > > ...
> > > I guess a synchronised scan could cause that, but I wouldn'
On Fri, Aug 14, 2020 at 05:15:20PM +0900, Michael Paquier wrote:
> Good catch it is. Your phrasing looks good to me.
Fixed as b4f1639. Thanks.
--
Michael
signature.asc
Description: PGP signature
On Mon, Aug 17, 2020 at 1:20 PM Tom Lane wrote:
> Thomas Munro writes:
> > I wonder what caused this[1] one-off failure to see tuples in clustered
> > order:
> > ...
> > I guess a synchronised scan could cause that, but I wouldn't expect one
> > here.
>
> Looking at its configuration, chipmunk
Thomas Munro writes:
> I wonder what caused this[1] one-off failure to see tuples in clustered order:
> ...
> I guess a synchronised scan could cause that, but I wouldn't expect one here.
Looking at its configuration, chipmunk uses
'extra_config' => {
...
Hi,
I wonder what caused this[1] one-off failure to see tuples in clustered order:
diff -U3
/home/pgbfarm/buildroot/REL_13_STABLE/pgsql.build/src/test/regress/expected/cluster.out
/home/pgbfarm/buildroot/REL_13_STABLE/pgsql.build/src/test/regress/results/cluster.out
---
/home/pgbfarm/buildroot/
Hi,
On 2020-08-16 17:28:46 -0400, Tom Lane wrote:
> Andres Freund writes:
> > For the first, one issue is that there's no obviously good candidate for
> > an uninitialized xid. We could use something like FrozenTransactionId,
> > which may never be in the procarray. But it's not exactly pretty.
>
Andres Freund writes:
> For the first, one issue is that there's no obviously good candidate for
> an uninitialized xid. We could use something like FrozenTransactionId,
> which may never be in the procarray. But it's not exactly pretty.
Huh? What's wrong with using InvalidTransactionId?
On Sun, Aug 16, 2020 at 2:11 PM Andres Freund wrote:
> For the first, one issue is that there's no obviously good candidate for
> an uninitialized xid. We could use something like FrozenTransactionId,
> which may never be in the procarray. But it's not exactly pretty.
Maybe it would make sense to
Hi,
On 2020-08-16 14:11:46 -0700, Andres Freund wrote:
> On 2020-08-16 13:52:58 -0700, Andres Freund wrote:
> > On 2020-08-16 13:31:53 -0700, Andres Freund wrote:
> > Gna, I think I see the problem. In at least one place I wrongly
> > accessed the 'dense' array of in-progress xids using the 'pgpr
Hi,
On 2020-08-16 13:52:58 -0700, Andres Freund wrote:
> On 2020-08-16 13:31:53 -0700, Andres Freund wrote:
> > I now luckily have a rr trace of the problem, so I hope I can narrow it
> > down to the original problem fairly quickly.
>
> Gna, I think I see the problem. In at least one place I wro
Hi,
On 2020-08-16 13:31:53 -0700, Andres Freund wrote:
> I now luckily have a rr trace of the problem, so I hope I can narrow it
> down to the original problem fairly quickly.
Gna, I think I see the problem. In at least one place I wrongly
accessed the 'dense' array of in-progress xids using the
Hi,
On 2020-08-16 16:17:23 -0400, Tom Lane wrote:
> I wrote:
> > It seems entirely likely that there's a timing component in this, for
> > instance autovacuum coming along at just the right time.
>
> D'oh. The attached seems to make it 100% reproducible.
Great! It interestingly didn't work as
I wrote:
> It seems entirely likely that there's a timing component in this, for
> instance autovacuum coming along at just the right time.
D'oh. The attached seems to make it 100% reproducible.
regards, tom lane
diff --git a/src/test/isolation/specs/freeze-the-dead.spec
On 2020-08-16 14:30:24 -0400, Tom Lane wrote:
> Andres Freund writes:
> > 690 successful runs later, it didn't trigger for me :(. Seems pretty
> > clear that there's another variable than pure chance, otherwise it seems
> > like that number of runs should have hit the issue, given the number of
>
Andres Freund writes:
> 690 successful runs later, it didn't trigger for me :(. Seems pretty
> clear that there's another variable than pure chance, otherwise it seems
> like that number of runs should have hit the issue, given the number of
> bf hits vs bf runs.
It seems entirely likely that the
Hi,
On 2020-08-15 09:42:00 -0700, Andres Freund wrote:
> On 2020-08-15 11:10:51 -0400, Tom Lane wrote:
> > We have two essentially identical buildfarm failures since these patches
> > went in:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2020-08-15%2011%3A27%3A32
>
27 matches
Mail list logo
