Re: pg_verify_checksums failure with hash indexes

On Tue, Aug 28, 2018 at 11:21:34AM +0200, Peter Eisentraut wrote: > The files in question correspond to > > hash_i4_index > hash_name_index > hash_txt_index The hash index code has been largely refactored in v10, so I would imagine that you can see the problem as well there. [... digging

Re: typcache.c typos

On Tue, Aug 28, 2018 at 01:57:12PM +0900, Amit Langote wrote: > On 2018/08/28 13:42, David Rowley wrote: >> On 28 August 2018 at 16:40, David Rowley >> wrote: >>> I've attached a patch to fix a typo in typcache.c. I ended up also >>> rephrasing the sentence since "information about data types

Re: Would it be possible to have parallel archiving?

Greetings, * hubert depesz lubaczewski (dep...@depesz.com) wrote: > I'm in a situation where we quite often generate more WAL than we can > archive. The thing is - archiving takes long(ish) time but it's > multi-step process and includes talking to remote servers over network. > > I tested that

pg_verify_checksums failure with hash indexes

This is reproducible with PG11 and PG12: initdb -k data postgres -D data make installcheck # shut down postgres with Ctrl-C pg_verify_checksums data pg_verify_checksums: checksum verification failed in file "data/base/16384/28647", block 65: calculated checksum DC70 but expected 0

Dimension limit in contrib/cube (dump/restore hazard?)

contrib/cube has an arbitrary limit of 100 on the number of dimensions in a cube, but it actually enforces that only in cube_in and cube_enlarge, with the other cube creation functions happy to create cubes of more dimensions. I haven't actually tested, but this implies that one can create cubes

Re: Stored procedures and out parameters

On 22/08/2018 20:22, Dave Cramer wrote: > I also agree with David that driver writers made the best out of the > situation with functions and we are now asking for the server to dual > purpose the call command. > > Is there a technical reason why this is not possible ? There are several areas of

Re: Would it be possible to have parallel archiving?

On Tue, Aug 28, 2018 at 08:33:11AM +0200, Alexander Kukushkin wrote: > There is the archive_status directory in pg_wal, and if there are > files with suffixes ".ready", you can archive not only the file which > was requested, but quite a few more if there are ".ready" files > available. After

Re: [HACKERS] [PATCH] kNN for SP-GiST

On Thu, Jul 26, 2018 at 8:39 PM Andrey Borodin wrote: > I'm not sure in architectural point of view: supporting two ways (list and > heap) to store result seems may be a bit heavy, but OK. At least, it has > meaningful benefits. It seems that Nikita have reworked it that way after my suspect

Re: Problem while setting the fpw with SIGHUP

Hello. At Sat, 25 Aug 2018 14:50:53 +0530, Amit Kapila wrote in > On Wed, Aug 1, 2018 at 12:56 PM Kyotaro HORIGUCHI > wrote: > > > > Thank you, Amit, Michael. > > > > Can you verify the first patch that I have posted above [1]? We can > commit it separately. Thanks for prompting. The

Re: FETCH FIRST clause PERCENT option

On Tue, Aug 21, 2018 at 3:50 PM Andres Freund wrote: > > Imagine volatile functions being used. That can be problematic because > of repeated side-effects, but also will lead to plainly wrong > results. Consider what happens with your approach where somebody does > something like WHERE value <

Re: pg_verify_checksums failure with hash indexes

Hi, On Tue, Aug 28, 2018 at 11:21:34AM +0200, Peter Eisentraut wrote: > This is reproducible with PG11 and PG12: > > initdb -k data > postgres -D data > > make installcheck > # shut down postgres with Ctrl-C > > pg_verify_checksums data > > pg_verify_checksums: checksum verification failed in

Re: Would it be possible to have parallel archiving?

On 8/28/18 8:32 AM, Stephen Frost wrote: > > * hubert depesz lubaczewski (dep...@depesz.com) wrote: >> I'm in a situation where we quite often generate more WAL than we can >> archive. The thing is - archiving takes long(ish) time but it's >> multi-step process and includes talking to remote

Catalog corruption

Hi, I sent already an email about this topic to pgsql-admins but I think that it might be more relevant to this mailing list. I'm trying to investigate a corruption that happened on a machine of one of our clients. A little background : -os Centos 6.6 -PostgreSQL v9.2.5 -I was asked to understand

Re: Something's busted in plpgsql composite-variable handling

2018-08-28 16:38 GMT+02:00 Jonathan S. Katz : > > > On Aug 26, 2018, at 4:09 PM, Tom Lane wrote: > > > > I wrote: > >> [ dropping and recreating a composite type confuses plpgsql ] > >> That's not very nice. What's worse is that it works cleanly in v10, > >> making this a regression, no doubt

Re: Something's busted in plpgsql composite-variable handling

> On Aug 28, 2018, at 10:45 AM, Pavel Stehule wrote: > > > > 2018-08-28 16:38 GMT+02:00 Jonathan S. Katz >: > > > On Aug 26, 2018, at 4:09 PM, Tom Lane > > wrote: > > > > I wrote: > >> [ dropping and recreating a composite type

Re: Fix help option of contrib/oid2name

On Mon, Aug 27, 2018 at 07:03:18PM +0900, Michael Paquier wrote: > Thanks, I have looked at the patch set. I have been through the set once again, and pushed both things. Thanks a lot Yamada-san. -- Michael signature.asc Description: PGP signature

Re: typcache.c typos

On 08/28/18 09:21, Michael Paquier wrote: > On Tue, Aug 28, 2018 at 01:57:12PM +0900, Amit Langote wrote: >> - * The type cache exists to speed lookup of certain information about data >> [ ... ] >> + * The type cache exists to speedup lookups of certain data type information >> >> Sorry if I'm

Re: pg_verify_checksums failure with hash indexes

Am Dienstag, den 28.08.2018, 11:21 +0200 schrieb Peter Eisentraut: > This is reproducible with PG11 and PG12: > > initdb -k data > postgres -D data > > make installcheck > # shut down postgres with Ctrl-C > I tried to reproduce this and by accident i had a blocksize=4 in my configure script,

Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

> On Aug 24, 2018, at 8:38 AM, Etsuro Fujita > wrote: > > (2018/08/24 11:47), Michael Paquier wrote: >> On Thu, Aug 23, 2018 at 10:00:49PM +0900, Etsuro Fujita wrote: >>> I tried this today, but doing git behind the corporate firewall doesn't >>> work. I don't know the clear cause of that, so

Re: Dimension limit in contrib/cube (dump/restore hazard?)

Hi! > 28 авг. 2018 г., в 8:29, Andrew Gierth > написал(а): > > contrib/cube has an arbitrary limit of 100 on the number of dimensions > in a cube, but it actually enforces that only in cube_in and > cube_enlarge, with the other cube creation functions happy to create > cubes of more

Re: Copy function for logical replication slots

On Tue, Aug 28, 2018 at 04:14:04PM +0900, Masahiko Sawada wrote: > I think the copying from a slot that already reserved WAL would be > helpful for backup cases (maybe you suggested?). Also, either way we > need to make a safe logic of acquring and releasing the source slot > for logical slots

Re: Why hash OIDs?

On Mon, Aug 27, 2018 at 10:12 PM, Andres Freund wrote: > Huh? Oids between, say, 1 and FirstNormalObjectId, are vastly more > common than the rest. And even after that, individual tables get large > clusters of sequential values to the global oid counter. Sure, but if you get a large cluster of

Re: Something's busted in plpgsql composite-variable handling

> On Aug 26, 2018, at 4:09 PM, Tom Lane wrote: > > I wrote: >> [ dropping and recreating a composite type confuses plpgsql ] >> That's not very nice. What's worse is that it works cleanly in v10, >> making this a regression, no doubt caused by the hacking I did on >> plpgsql's handling of

Re: Reopen logfile on SIGHUP

On Tue, Aug 21, 2018 at 4:48 AM Kyotaro HORIGUCHI wrote: > > At Fri, 10 Aug 2018 15:33:26 +0300, Alexander Kuzmenkov > wrote in > <5142559a-82e6-b3e4-d6ed-8fd2d240c...@postgrespro.ru> > > On 08/09/2018 10:33 AM, Kyotaro HORIGUCHI wrote: > > > > > > - Since I'm not sure unlink is signal-handler

Re: Stored procedures and out parameters

On Tuesday, August 28, 2018, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > First of all, what do you want to do with the function return value > when you use CALL? > Place it in the result set. > And would you expect a function that is invoked via CALL to have a > non-atomic

Re: pg_verify_checksums failure with hash indexes

On Tue, Aug 28, 2018 at 6:43 PM Michael Paquier wrote: > > On Tue, Aug 28, 2018 at 11:21:34AM +0200, Peter Eisentraut wrote: > > The files in question correspond to > > > > hash_i4_index > > hash_name_index > > hash_txt_index > > The hash index code has been largely refactored in v10, so I would

logical decoding: ABI break in 10.5 et al

Hello In the process of fixing a bug, I inadvertently broke ABI compatibility in all released branches that sport logical decoding. [TL;DR: I propose to set up abidiff.postgresql.org.] This is the commit: Author: Alvaro Herrera Branch: master Release: REL_11_BR [f49a80c48] 2018-06-26 16:48:10

Re: typcache.c typos

David Rowley writes: > On 28 August 2018 at 16:40, David Rowley wrote: >> I've attached a patch to fix a typo in typcache.c. I ended up also >> rephrasing the sentence since "information about data types that is", >> almost made me also want to change "is" to "are", since "types" is >> plural.

Re: Why hash OIDs?

Andres Freund writes: > On 2018-08-28 14:45:49 +1200, Thomas Munro wrote: >> Yeah, it would be a terrible idea as a general hash function for use >> in contexts where the "avalanche effect" assumption is made about >> information being spread out over the bits (the HJ batching code >> wouldn't

Re: Something's busted in plpgsql composite-variable handling

2018-08-28 17:04 GMT+02:00 Jonathan S. Katz : > > On Aug 28, 2018, at 10:45 AM, Pavel Stehule > wrote: > > > > 2018-08-28 16:38 GMT+02:00 Jonathan S. Katz : > >> >> > On Aug 26, 2018, at 4:09 PM, Tom Lane wrote: >> > >> > I wrote: >> >> [ dropping and recreating a composite type confuses

Re: logical decoding: ABI break in 10.5 et al

Re: Alvaro Herrera 2018-08-28 <20180828153806.fgfnul2imeltzmib@alvherre.pgsql> > In order to forestall this from happening again, I'm proposing a new > community service that will let us know of ABI incompatibilities > introduced by commits, hopefully before they become full-fledged minor >

Re: Would it be possible to have parallel archiving?

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 8/28/18 8:32 AM, Stephen Frost wrote: > > > > * hubert depesz lubaczewski (dep...@depesz.com) wrote: > >> I'm in a situation where we quite often generate more WAL than we can > >> archive. The thing is - archiving takes long(ish) time

Re: Dimension limit in contrib/cube (dump/restore hazard?)

Hi! On Tue, Aug 28, 2018 at 6:21 PM Andrey Borodin wrote: > I belive cube construction from array\arrays should check size of arrays. Makes sense to me. > Also there are some unexpected cube dimensionality reduction like in > cube_enlarge > if (n > CUBE_MAX_DIM) > n =

Re: pg_dump test instability

Stephen Frost writes: > Parallel *restore* can be done from either a custom-format dump or from > a directory-format dump. I agree that we should seperate the concerns > and perform independent sorting on the restore side of things based on > the relative sizes of tables in the dump (be it

Re: Dimension limit in contrib/cube (dump/restore hazard?)

> 28 авг. 2018 г., в 14:18, Alexander Korotkov > написал(а): > > OK, but I think cube_c_f8() and cube_c_f8_f8() also need to be > revised. Also, I think this behavior should be covered by regression > tests. True. Also there's one case in cube_subset. Best regards, Andrey Borodin.

Re: More parallel pg_dump bogosities

On 2018-Aug-28, Tom Lane wrote: > ... just when you thought it was safe to go back in the water ... > > Doesn't pg_backup_archiver.c's identify_locking_dependencies() need to > treat POLICY and ROW SECURITY items as requiring exclusive lock on > the referenced table? Those commands definitely

Re: csv format for psql

Fabien COELHO wrote: > My point was more about the documentation which should be clear about what > is the EOL. I understand from your point above that the EOL is the > platform-specific one, which is yet again fine with me, but should be said > clearly in the documentation? Okay,

Re: Some pgq table rewrite incompatibility with logical decoding?

> > Jeremy, are you able to reproduce the issue locally, using pgq? That would >> be very valuable. > > Tomas et al: We have hit this error again, and we plan to snapshot the database as to be able to do whatever troubleshooting we can. If someone could provide me guidance as to what exactly you

Re: csv format for psql

Bonjour Daniel, Currently popt->topt.fieldSepCsv can't be NULL so I've simplified this to just return pset_quoted_string(popt->topt.fieldSepCsv). Ok. While testing I found a small issue if "fieldsep_csv" is set to a strange value: \pset format_csv ',,' You meant \pset fieldsep_csv

Re: TupleTableSlot abstraction

On Fri, Aug 24, 2018 at 6:46 AM, Andres Freund wrote: > Hi, > > On 2018-08-20 19:51:33 +0530, Ashutosh Bapat wrote: >> Sorry, forgot about that. Here's the patch set with that addressed. > > Btw, you attach files as tar.zip, but they're actually gzip > compressed... I am using "tar -zcvf" to

Re: Catalog corruption

On Tue, Aug 28, 2018 at 7:36 AM, Mariel Cherkassky wrote: > Afterwards I vacuumed all the databases but nothing helped. I tried to > reindex the databases but I got the next error : > > 2018-08-28 21:50:03 +08 db2 24360 ERROR: could not access status of > transaction 32212695 > 2018-08-28

Re: More parallel pg_dump bogosities

... just when you thought it was safe to go back in the water ... Doesn't pg_backup_archiver.c's identify_locking_dependencies() need to treat POLICY and ROW SECURITY items as requiring exclusive lock on the referenced table? Those commands definitely acquire AccessExclusiveLock in a quick test.

Re: Would it be possible to have parallel archiving?

> 28 авг. 2018 г., в 17:41, Stephen Frost написал(а): > > Pushing files which are indicated by archive status as being ready is > absolutely an entirely different thing from whacking around the status > files themselves which PG is managing itself. I disagree. Returning archive_command exit

Re: Would it be possible to have parallel archiving?

> 28 авг. 2018 г., в 14:08, Stephen Frost написал(а): > > Greetings, > > * David Steele (da...@pgmasters.net ) wrote: >> On 8/28/18 8:32 AM, Stephen Frost wrote: >> To be clear, pgBackRest uses the .ready files in archive_status to >> parallelize archiving but

Re: Would it be possible to have parallel archiving?

On Tue, Aug 28, 2018 at 05:20:10PM -0400, Stephen Frost wrote: > Absolutely. External processes shouldn't be changing the files written > out and managed by the core system. +1. Archiving commands should not mess up directly with the contents the backend is managing. -- Michael signature.asc

Re: some pg_dump query code simplification

Peter Eisentraut writes: > There is a lot of version dependent code in pg_dump now, especially > per-version queries. The way they were originally built was that we > just have an entirely separate query per version. But as the number of > versions and the size of the query grows, this becomes

Re: some pg_dump query code simplification

Stephen Frost writes: > I wonder- what if we had an option to pg_dump to explicitly tell it what > the server's version is and then have TAP tests to run with different > versions? Uh ... telling it what the version is doesn't make that true, so I'd have no confidence in a test^H^H^H^Hkluge done

Re: some pg_dump query code simplification

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Stephen Frost writes: >>> I wonder- what if we had an option to pg_dump to explicitly tell it what >>> the server's version is and then have TAP tests to run with different >>> versions? >> Uh ... telling it what the version is

pg_dump --load-via-partition-root vs. parallel restore

Parallel pg_restore generally assumes that the archive file is telling it the truth about data dependencies; in particular, that a TABLE DATA item naming a particular target table is loading data into exactly that table. --load-via-partition-root creates a significant probability that that

Re: Would it be possible to have parallel archiving?

> 28 авг. 2018 г., в 17:07, Stephen Frost написал(а): > > Greetings, > > * Andrey Borodin (x4...@yandex-team.ru) wrote: >>> 28 авг. 2018 г., в 14:08, Stephen Frost написал(а): >>> * David Steele (da...@pgmasters.net ) wrote: On 8/28/18 8:32 AM, Stephen Frost

Re: Would it be possible to have parallel archiving?

Greetings, * David Steele (da...@pgmasters.net) wrote: > On 8/28/18 4:34 PM, Andrey Borodin wrote: > >> > >> I still don't think it's a good idea and I specifically recommend > >> against making changes to the archive status files- those are clearly > >> owned and managed by PG and should not be

Re: some pg_dump query code simplification

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > There is a lot of version dependent code in pg_dump now, especially > > per-version queries. The way they were originally built was that we > > just have an entirely separate query per version. But as the number

Re: Some pgq table rewrite incompatibility with logical decoding?

On 08/28/2018 07:41 PM, Jeremy Finzel wrote: > Jeremy, are you able to reproduce the issue locally, using pgq? > That would be very valuable. > > > Tomas et al: > > We have hit this error again, and we plan to snapshot the database as to > be able to do whatever troubleshooting

Re: Would it be possible to have parallel archiving?

Greetings, * Andrey Borodin (x4...@yandex-team.ru) wrote: > > 28 авг. 2018 г., в 14:08, Stephen Frost написал(а): > > * David Steele (da...@pgmasters.net ) wrote: > >> On 8/28/18 8:32 AM, Stephen Frost wrote: > >> To be clear, pgBackRest uses the .ready files in

Re: Some pgq table rewrite incompatibility with logical decoding?

> > We have hit this error again, and we plan to snapshot the database as to > be able to do whatever troubleshooting we can. > I am happy to report that we were able to get replication working again by running snapshots of the systems in question on servers running the latest point release

some pg_dump query code simplification

There is a lot of version dependent code in pg_dump now, especially per-version queries. The way they were originally built was that we just have an entirely separate query per version. But as the number of versions and the size of the query grows, this becomes unwieldy. So I tried, as an

Re: Some pgq table rewrite incompatibility with logical decoding?

Hi Jeremy, On 08/28/2018 10:46 PM, Jeremy Finzel wrote: > We have hit this error again, and we plan to snapshot the database > as to be able to do whatever troubleshooting we can.  > > > I am happy to report that we were able to get replication working again > by running snapshots of

Re: some pg_dump query code simplification

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> Stephen Frost writes: > >>> I wonder- what if we had an option to pg_dump to explicitly tell it what > >>> the server's version is and then have TAP tests to run with

Re: Would it be possible to have parallel archiving?

Greetings, * Andrey Borodin (x4...@yandex-team.ru) wrote: > > 28 авг. 2018 г., в 17:07, Stephen Frost написал(а): > > I still don't think it's a good idea and I specifically recommend > > against making changes to the archive status files- those are clearly > > owned and managed by PG and should

Re: Would it be possible to have parallel archiving?

On 8/28/18 4:34 PM, Andrey Borodin wrote: >> >> I still don't think it's a good idea and I specifically recommend >> against making changes to the archive status files- those are clearly >> owned and managed by PG and should not be whacked around by external >> processes. > If you do not write to

Re: some pg_dump query code simplification

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I wonder- what if we had an option to pg_dump to explicitly tell it what > > the server's version is and then have TAP tests to run with different > > versions? > > Uh ... telling it what the version is doesn't make

Re: More parallel pg_dump bogosities

Alvaro Herrera writes: > On 2018-Aug-28, Tom Lane wrote: >> Doesn't pg_backup_archiver.c's identify_locking_dependencies() need to >> treat POLICY and ROW SECURITY items as requiring exclusive lock on >> the referenced table? Those commands definitely acquire >> AccessExclusiveLock in a quick

Re: Why hash OIDs?

On Wed, Aug 29, 2018 at 1:37 AM Tom Lane wrote: > Andres Freund writes: > > On 2018-08-28 14:45:49 +1200, Thomas Munro wrote: > >> Yeah, it would be a terrible idea as a general hash function for use > >> in contexts where the "avalanche effect" assumption is made about > >> information being

Re: Reopen logfile on SIGHUP

At Tue, 28 Aug 2018 18:50:31 +0300, Alexander Korotkov wrote in > On Tue, Aug 21, 2018 at 4:48 AM Kyotaro HORIGUCHI > wrote: > > > > At Fri, 10 Aug 2018 15:33:26 +0300, Alexander Kuzmenkov > > wrote in > > <5142559a-82e6-b3e4-d6ed-8fd2d240c...@postgrespro.ru> > > > On 08/09/2018 10:33 AM,

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

On 2018-08-28 19:56:58 -0700, Andres Freund wrote: > Hi Everyone, > > > Tom, I think this could use your eyes. > > > On 2018-08-28 00:52:13 -0700, Andres Freund wrote: > > I've a few leads that I'm currently testing out. One observation I think > > might be crucial is that the problem, in

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

On 2018-08-28 23:18:25 -0400, Tom Lane wrote: > Andres Freund writes: > > Tom, I think this could use your eyes. > > I've had no luck reproducing it locally ... do you have a recipe > for that? It can reproduce reliably with the three scripts attached: psql -c' drop table if exists t; create

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

Andres Freund writes: > On 2018-08-28 20:27:14 -0700, Andres Freund wrote: >> Locally that triggers the problem within usually a few seconds. > FWIW, it does so including versions as old as 9.2. Interesting. One thing I'd like to know is why this only started showing up in the buildfarm a few

Re: Why hash OIDs?

On Wed, Aug 29, 2018 at 2:09 AM Robert Haas wrote: > On Mon, Aug 27, 2018 at 10:12 PM, Andres Freund wrote: > > Huh? Oids between, say, 1 and FirstNormalObjectId, are vastly more > > common than the rest. And even after that, individual tables get large > > clusters of sequential values to the

Re: Postmaster doesn't send SIGTERM to bgworker during fast shutdown when pmState == PM_STARTUP

On Mon, Aug 27, 2018 at 07:34:55PM -0700, Michael Paquier wrote: > That seems like a good catch and a correct fix to me. The handling of > SIGINT is inconsistent with SIGTERM in pmdie(). I would just add a > comment to mention that at this stage only the startup process is > running, and that it

Re: Why hash OIDs?

On Wed, Aug 29, 2018 at 11:05 AM Thomas Munro wrote: > On Wed, Aug 29, 2018 at 2:09 AM Robert Haas wrote: > > rhaas=# create table a (x serial primary key); > > CREATE TABLE > > rhaas=# create table b (x serial primary key); > > CREATE TABLE > > rhaas=# select 'a'::regclass::oid,

Re: Copy function for logical replication slots

On Tue, Aug 28, 2018 at 10:34 PM, Michael Paquier wrote: > On Tue, Aug 28, 2018 at 04:14:04PM +0900, Masahiko Sawada wrote: >> I think the copying from a slot that already reserved WAL would be >> helpful for backup cases (maybe you suggested?). Also, either way we >> need to make a safe logic of

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

On 2018-08-28 20:27:14 -0700, Andres Freund wrote: > Locally that triggers the problem within usually a few seconds. FWIW, it does so including versions as old as 9.2. Now I need to look for power for my laptop and some for me ;)

Re: BUG #15182: Canceling authentication due to timeout aka Denial of Service Attack

Hi all, Here is a summary of what has happened since this thread has been created. Three problems reported on this thread have been solved and resulted in different commits for early lock lookups: - VACUUM FULL, patched on 12~:

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

Hi Everyone, Tom, I think this could use your eyes. On 2018-08-28 00:52:13 -0700, Andres Freund wrote: > I've a few leads that I'm currently testing out. One observation I think > might be crucial is that the problem, in Tomas' testcase with just > VACUUM FULL of pg_class and INSERTs into

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

Andres Freund writes: > Tom, I think this could use your eyes. I've had no luck reproducing it locally ... do you have a recipe for that? regards, tom lane

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

On 2018-08-28 23:32:51 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2018-08-28 20:27:14 -0700, Andres Freund wrote: > >> Locally that triggers the problem within usually a few seconds. > > > FWIW, it does so including versions as old as 9.2. 9.0 as well, so it's definitely not some

Re: Refactor textToQualifiedNameList()

On Tue, 28 Aug 2018 11:49:26 +0900 (Tokyo Standard Time) Kyotaro HORIGUCHI wrote: > At Fri, 24 Aug 2018 20:44:12 +0900, Yugo Nagata wrote > in <20180824204412.150979ae6b283ddb639f9...@sraoss.co.jp> > > When working on other patch[1], I found there are almost same > > functions,

Re: Why hash OIDs?

Thomas Munro writes: > On Wed, Aug 29, 2018 at 11:05 AM Thomas Munro > wrote: >> On Wed, Aug 29, 2018 at 2:09 AM Robert Haas wrote: >>> rhaas=# create table a (x serial primary key); >>> CREATE TABLE >>> rhaas=# create table b (x serial primary key); >>> CREATE TABLE >>> rhaas=# select

Re: Reopen logfile on SIGHUP

At Tue, 21 Aug 2018 11:27:46 +0900, Michael Paquier wrote in <20180821022745.ge2...@paquier.xyz> > On Tue, Aug 21, 2018 at 09:26:54AM +0900, Kyotaro HORIGUCHI wrote: > > I suspect that something bad can happen on Windows. > > [troll mode] > More and even worse things than that could happen on

Would it be possible to have parallel archiving?

Hi, I'm in a situation where we quite often generate more WAL than we can archive. The thing is - archiving takes long(ish) time but it's multi-step process and includes talking to remote servers over network. I tested that simply by running archiving in parallel I can easily get 2-3 times higher

Re: Would it be possible to have parallel archiving?

Hi, There is the archive_status directory in pg_wal, and if there are files with suffixes ".ready", you can archive not only the file which was requested, but quite a few more if there are ".ready" files available. After that you have to rename ".ready" to ".done". Postgres will not call

Re: Copy function for logical replication slots

On Mon, Aug 20, 2018 at 2:53 PM, Michael Paquier wrote: > On Tue, Aug 14, 2018 at 01:38:23PM +0900, Masahiko Sawada wrote: >> On Thu, Jul 12, 2018 at 9:28 PM, Masahiko Sawada >> wrote: >>> Attached new version of patch incorporated the all comments I got from >>> Michael-san. >>> >>> To prevent

Re: some more error location support

Even if there is some under-the-hood garbage collection, I'd suggest to add a free after the call to ComputePartitionAttrs. Hmm, I didn't know about free_parsestate(). It doesn't seem to be used consistently. I suppose you'll want to use it when you have a target relation that will be

Re: buildfarm: could not read block 3 in file "base/16384/2662": read only 0 of 8192 bytes

Hi, Tomas provided me with a machine where the problem was reproducible (Thanks again!). I first started to make sure a54e1f158 is unrelated - and indeed, the problem appears independently. I've a few leads that I'm currently testing out. One observation I think might be crucial is that the