On Fri, Apr 03, 2020 at 10:19:21AM -0400, Robert Haas wrote:
> What I'm thinking about is: suppose we add an option to pg_basebackup
> with a name like --pipe-output. This would be mutually exclusive with
> -D, but would work at least with -Ft and maybe also with -Fp. The
> argument to --pipe-outpu
On Sat, 4 Apr 2020 at 18:04, Julien Rouhaud wrote:
>
> On Fri, Apr 03, 2020 at 11:39:11AM +0200, Julien Rouhaud wrote:
> > On Fri, Apr 03, 2020 at 12:24:50PM +0900, Masahiko Sawada wrote:
> > >
> > > check_relation_fork() seems to quite depends on pg_check_relation()
> > > because the returned tup
On Fri, Mar 27, 2020 at 11:22 AM Andres Freund wrote:
> I've found rr [1] very useful to debug issues in postgres. The ability
> to hit a bug, and then e.g. identify a pointer with problematic
> contents, set a watchpoint on its contents, and reverse-continue is
> extremely powerful.
I agree that
Nikita Glukhov writes:
> Fixed patch attached.
I looked through this again, and I still don't feel very happy with it.
As I mentioned upthread, I'm not convinced that we ought to have
*both* quoting and backslash-escaping in these datatypes. TIMTOWTDI
may be a virtue to the Perl crowd, but to a
On Fri, Apr 03, 2020 at 09:04:34PM +0500, Ibrar Ahmed wrote:
> Here is the latest patch rebased with master
> (19db23bcbda99e93321cb0636677ec9c6e121a2a) Fri Apr 3 12:20:42 2020. Patch
> fix all the issues, after the parallel vacuum patch. The patch works in
> case of a non-parallel option and allo
On 2020-04-03 21:51, Anna Akenteva wrote:
I did some code cleanup and added tests - both for the standalone WAIT
FOR statement and for WAIT FOR as a part of BEGIN. The new patch is
attached.
I did more cleanup and code optimization on waiting events on latch.
And rebase patch.
--
Ivan Kartysho
On Sun, Apr 5, 2020 at 10:34 AM Mark Dilger
wrote:
> > On Apr 4, 2020, at 7:11 AM, Thomas Munro wrote:
> > However, I am getting cold feet about the new function names. The
> > existing naming structure made sense when all this stuff originated in
> > a contrib module with "txid_" as a prefix al
> On Apr 4, 2020, at 7:11 AM, Thomas Munro wrote:
>
> On Sat, Apr 4, 2020 at 4:45 AM Mark Dilger
> wrote:
>> FYI, (not the responsibility of this patch), we never quite define what the
>> abbreviation "xip" stands for. If "Active xid8s at the time of the
>> snapshot." were rewritten as "I
On Sat, Apr 04, 2020 at 06:24:34PM -0400, Tom Lane wrote:
> Shouldn't the CF entry get closed?
Once the buildfarm is clean for a day, sure. The buildfarm has already
revealed a missing perl2host call.
Robert Haas writes:
> On Wed, Apr 1, 2020 at 11:51 PM Noah Misch wrote:
>> I've translated the non-vote comments into estimated votes of -0.3, -0.6,
>> -0.4, +0.5, and -0.3. Hence, I revoke the plan to back-patch.
> FWIW, I also think that it would be better not to back-patch.
FWIW, I also con
On Sun, Apr 5, 2020 at 2:36 AM Robert Haas wrote:
> eelpout is unhappy because:
>
> +WARNING: could not remove shared memory segment
> "/PostgreSQL.248989127": No such file or directory
> +WARNING: could not remove shared memory segment
> "/PostgreSQL.1450751626": No such file or directory
Seem
Jaime Casanova writes:
> Running sqlsmith on master i got an assertion failure on parse_coerce.c:2049
Hmph, or more simply:
regression=# select array_in('{1,2,3}',23,-1);
server closed the connection unexpectedly
which is a case that worked before. The core of the problem is
that array_in() vi
Hi,
Running sqlsmith on master i got an assertion failure on parse_coerce.c:2049
This is a minimal query to reproduce in an empty database, i also
attached the stack trace
"""
select
pg_catalog.array_in(
cast(pg_catalog.regoperatorout(
cast(cast(null as regoperator) as regoperator))
Richard Guo writes:
> Rebased the patch with latest master and also addressed the test case
> failure reported by PostgreSQL Patch Tester.
I looked this patch over, but I don't like it too much: it seems very
brute-force (and badly under-commented). Creating all those extra
RestrictInfos isn't t
Hi,
Right now we prevent dead rows in non-shared catalog tables from being
removed whenever there is a logical slot with an older catalog
xmin. Obviously that's required when the slot is in the current
database, but it's not when the slot is in a different database.
I don't think we can afford to
Robert Haas writes:
> On Sat, Apr 4, 2020 at 10:57 AM Tom Lane wrote:
>> What is odd is that
>> (AFAIR) we've never seen this before. Maybe somebody recently added
>> an error cursor callback in a place that didn't have it before, and
>> is involved in SQL-function processing? None of the commi
On Sat, Apr 4, 2020 at 10:57 AM Tom Lane wrote:
> It's not so surprising that we could get a different result that way
> from a CLOBBER_CACHE_ALWAYS animal like hyrax, since CCA-forced
> cache reloads would cause extra stack expenditure at a lot of places.
> And it could vary depending on totally
On Sat, Apr 4, 2020 at 2:55 AM Fabien COELHO wrote:
>
> > BTW it's now visible at:
> > https://www.postgresql.org/docs/devel/glossary.html
Nice. I went looking for it yesterday and the docs hadn't rebuilt yet.
> ISTM that occurrences of these words elsewhere in the documentation should
> link
Mark Lorenz writes:
> with a bit space to this issue, I re-read your comments. I am beginning
> to understand what you mean or - better - what's wrong with my thoughts.
> When I understand you correctly, you say, the WW can start at any
> weekday, and is not fixed to Sunday, right? In your opin
Amit Langote writes:
> One thing to I must clarify: coverage for most of pgoutput.c looks
> okay on each run. I am concerned that the coverage for the code added
> by the patch is shown to be close to zero, which is a mystery to me,
> because I can confirm by other means such as debugging elogs()
Robert Haas writes:
> hyrax's last run was before any of this happened, so it seems to have
> an unrelated problem. The last two runs, three and six days ago, both
> failed like this:
> -ERROR: stack depth limit exceeded
> +ERROR: stack depth limit exceeded at character 8
> Not sure what that'
Robert Haas writes:
> On Fri, Apr 3, 2020 at 8:18 PM Tom Lane wrote:
>> I suppose that judicious s/time_t/pg_time_t/ would fix this.
> I think you sent this email just after I pushed
> db1531cae00941bfe4f6321fdef1e1ef355b6bed, or maybe after I'd committed
> it locally and just before I pushed it
On Sat, Apr 4, 2020 at 5:56 PM Petr Jelinek wrote:
> On 04/04/2020 07:25, Tom Lane wrote:
> > Petr Jelinek writes:
> >> On 03/04/2020 17:51, Tom Lane wrote:
> >>> But the forked-off children have to write the gcov files independently,
> >>> don't they?
> >
> >> Hmm that's very good point. I did s
On Fri, Apr 3, 2020 at 10:43 PM Robert Haas wrote:
> I think I've done about as much as I can do for tonight, though. Most
> things are green now, and the ones that aren't are failing because of
> stuff that is at least plausibly fixed. By morning it should be
> clearer how much broken stuff is le
On Fri, Apr 3, 2020 at 8:18 PM Tom Lane wrote:
> BTW, some of the buildfarm is showing a simpler portability problem:
> they think you were too cavalier about the difference between time_t
> and pg_time_t. (On a platform with 32-bit time_t, that's an actual
> bug, probably.) lapwing is actually
On Fri, Apr 3, 2020 at 11:06 PM Andres Freund wrote:
> On 2020-04-03 20:48:09 -0400, Robert Haas wrote:
> > 'serinus' is also failing. This is less obviously related:
>
> Hm. Tests passed once since then.
Yeah, but conchuela also failed once in what I think was a similar
way. I suspect the fix I
- Server: is that really our definition?
I thought that "server" is what the glossary defines as "instance", and
the thing called "server" in the glossary should really be called "host".
Maybe I am too Unix-centered.
Many people I know use "instance" synonymous to "cluster".
Cur
On Sat, Apr 4, 2020 at 6:13 AM Tom Lane wrote:
> Amit Langote writes:
> > Updated patches attached.
>
> I looked through these and committed 0001+0002, with some further
> comment-polishing. However, I have no faith at all in 0003.
Thanks for the review.
> It is
> blithely digging through COA
On Sat, Apr 04, 2020 at 02:39:32PM +0530, Amit Kapila wrote:
> On Sat, Apr 4, 2020 at 2:24 PM Julien Rouhaud wrote:
> > >
> > > We can add if we want but I am not able to convince myself for that.
> > > Do you have any use case in mind? I think in most of the cases
> > > (except for hint-bit WAL)
On Sat, Apr 4, 2020 at 2:24 PM Julien Rouhaud wrote:
> >
> > We can add if we want but I am not able to convince myself for that.
> > Do you have any use case in mind? I think in most of the cases
> > (except for hint-bit WAL) it will be zero. If we are not sure of this
> > we can also discuss it
On Fri, Apr 03, 2020 at 11:39:11AM +0200, Julien Rouhaud wrote:
> On Fri, Apr 03, 2020 at 12:24:50PM +0900, Masahiko Sawada wrote:
> >
> > check_relation_fork() seems to quite depends on pg_check_relation()
> > because the returned tuplestore is specified by pg_check_relation().
> > It's just an i
On Sat, Apr 4, 2020 at 12:33 AM Andres Freund wrote:
>
> On 2020-04-03 14:32:09 +0530, Amit Kapila wrote:
> >
> > Agreed, but OTOH, not giving time to Kevin or others who might be
> > interested to support this work is also not fair. I think once
> > somebody comes up with patches for problems we
On 04/04/2020 07:25, Tom Lane wrote:
Petr Jelinek writes:
On 03/04/2020 17:51, Tom Lane wrote:
But the forked-off children have to write the gcov files independently,
don't they?
Hmm that's very good point. I did see these missing coverage issue when
running tests that explicitly start more
On Sat, Apr 04, 2020 at 02:12:59PM +0530, Amit Kapila wrote:
> On Sat, Apr 4, 2020 at 11:33 AM Julien Rouhaud wrote:
> >
> > On Sat, Apr 04, 2020 at 10:38:14AM +0530, Amit Kapila wrote:
> >
> > > > The patch-2 might need to be
> > > > rebased if the other related patch [2] got committed first and
On Sat, Apr 4, 2020 at 11:33 AM Julien Rouhaud wrote:
>
> On Sat, Apr 04, 2020 at 10:38:14AM +0530, Amit Kapila wrote:
>
> > > The patch-2 might need to be
> > > rebased if the other related patch [2] got committed first and we
> > > might need to tweak a bit based on the input from other thread
On 2020-04-03 19:55, Robert Haas wrote:> I think this patch needs to be
reverted. The only places where it
changes anything are places where we were about to throw some error
anyway. But as Andres's analysis shows, that's not nearly good enough.
OK, reverted.
36 matches
Mail list logo
