Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Wed, Nov 7, 2018 at 12:58 PM Alvaro Herrera wrote: > On 2018-Nov-06, Robert Haas wrote: > > - get_partition_dispatch_recurse and ExecCreatePartitionPruneState > > both call RelationGetPartitionDesc. > > My patch deals with this by caching descriptors in the active snapshot. > So those two

Does slot_deform_tuple need to care about dropped columns?

Hi, Currently functions like slot_getattr() first check if the attribute is already deformed: Datum slot_getattr(TupleTableSlot *slot, int attnum, bool *isnull) { ... /* * fast path if desired attribute already cached */ if (attnum <= slot->tts_nvalid) {

Re: [HACKERS] [PATCH] Generic type subscripting

> On Wed, 7 Nov 2018 at 17:09, Pavel Stehule wrote: > > I don't agree. If we use a same syntax for some objects types, we should to > enforce some consistency. Just to make it clear, consistency between what? > I don't think so you should to introduce nulls for JSONs. In this case, the >

Re: Connection limit doesn't work for superuser

On 11/7/18 10:49 AM, Robert Haas wrote: On Wed, Nov 7, 2018 at 1:14 PM Tom Lane wrote: I think that having superusers be immune to datconnlimit is actually the right thing; for one reason, because datconnlimit can be set by database owners, who should not be able to lock superusers out of

Re: partitioned indexes and tablespaces

On Wed, Nov 7, 2018 at 2:33 PM Tomas Vondra wrote: > FWIW, it was mentioned that "your only concurring vote came from someone > with whom you share an employer" which kind suggests opinions/votes from > people working for the same company are somehow less honest/valuable. I > find that annoying

Re: fix psql \conninfo & \connect when using hostaddr

st 7. 11. 2018 v 15:11 odesílatel Arthur Zakirov napsal: > Hello all, > > On 07.11.2018 16:23, Pavel Stehule wrote: > > pá 26. 10. 2018 v 15:55 odesílatel Fabien COELHO > > napsal: > > > > > > This is a follow-up to another patch I posted about libpq confusing >

Re: valgrind on initdb

On 2018-11-07 09:37:37 -0500, Andrew Dunstan wrote: > > On 11/7/18 9:11 AM, Tomas Vondra wrote: > > > > On 11/7/18 2:47 PM, John Naylor wrote: > > > On 11/7/18, Jesper Pedersen wrote: > > > > Hi, > > > > > > > > While looking at [1] (included in 23315.log) there are other warnings as > > > >

Re: file cloning in pg_upgrade and CREATE DATABASE

On 19/10/2018 01:50, Michael Paquier wrote: > On Thu, Oct 18, 2018 at 11:59:00PM +0200, Peter Eisentraut wrote: >> New patch that removes all the various reflink modes and adds a new >> option --clone that works similar to --link. I think it's much cleaner now. > > Thanks Peter for the new

Re: Does slot_deform_tuple need to care about dropped columns?

Andres Freund writes: > ... in the case the attribute isn't already deformed, the > following hunk exists: > /* >* If the attribute's column has been dropped, we force a NULL result. >* This case should not happen in normal use, but it could happen if we >* are

Re: partitioned indexes and tablespaces

On Wed, Nov 7, 2018 at 1:22 PM Alvaro Herrera wrote: > > But maybe you've adopted that policy already. You back-patched a > > behavior change 2 days before a minor release when the vote was 2-3 > > against the change. > > It was? This is my count: > For: Alvaro, Andrew, Tom > Against: Michael,

Re: Connection limit doesn't work for superuser

On Wed, Nov 7, 2018 at 1:14 PM Tom Lane wrote: > I think that having superusers be immune to datconnlimit is actually > the right thing; for one reason, because datconnlimit can be set by > database owners, who should not be able to lock superusers out of > their database. Yeah, that's a

Re: Connection limit doesn't work for superuser

"David G. Johnston" writes: > On the accept side, which I'm leaning toward, is that superuser is > already constrained by max_connections and, in addition, the > implications of setting this value are straight-forward and it obvious > requires intent on the part of the user. Its not a "foot-gun"

Re: partitioned indexes and tablespaces

On 2018-Nov-07, Robert Haas wrote: > On Wed, Nov 7, 2018 at 10:46 AM Alvaro Herrera > wrote: > > I think 11.0 is ready for testing that a migration from a production > > running 10.x, but not for just blindly migrating. If you wanted to take > > such a leap of faith, surely you'd wait for 11.1

Re: [HACKERS] Surjective functional indexes

Robert Haas writes: > On Fri, May 11, 2018 at 11:01 AM, Simon Riggs wrote: I have no problem if you want to replace this with an even better design in a later release. >>> Meh. The author / committer should get a patch into the right shape >> They have done, at length. Claiming

Re: Speeding up INSERTs and UPDATEs to partitioned tables

Hi David, On 11/7/18 6:46 AM, David Rowley wrote: I've attached a patch which does this. It adds a new struct named PartitionRoutingInfo into ResultRelInfo and pulls 3 of the 4 arrays out of PartitionTupleRouting. There are fields for each of what these arrays used to store inside the

Re: file cloning in pg_upgrade and CREATE DATABASE

Peter Eisentraut writes: > Committed, thanks. It seems unfortunate that there is no test coverage in the committed patch. I realize that it may be hard to test given the filesystem dependency, but how will we know if it works at all? regards, tom lane

Re: partitioned indexes and tablespaces

On 11/7/18 7:41 PM, Robert Haas wrote: > On Wed, Nov 7, 2018 at 1:22 PM Alvaro Herrera > wrote: >>> But maybe you've adopted that policy already. You back-patched a >>> behavior change 2 days before a minor release when the vote was 2-3 >>> against the change. >> >> It was? This is my

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

On Tue, Nov 6, 2018 at 10:05 AM chenhj wrote: > I analyzed the btree block where lwlock deadlock occurred, as follows: Thank you for doing this important work. You're using Postgres 10.2. While that version isn't current with all GIN bug fixes, it does have this important one: "Ensure that

Re: Calculate total_table_pages after set_base_rel_sizes()

David Rowley writes: > [ v2-0001-Calculate-total_table_pages-after-set_base_rel_si.patch ] Pushed with cosmetic adjustments. The reason it's okay to not check for appendrels in this loop is now quite different from the reason it was okay before, so I didn't like the fact that you'd just

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On 2018-Nov-06, Robert Haas wrote: > - get_partition_dispatch_recurse and ExecCreatePartitionPruneState > both call RelationGetPartitionDesc. My patch deals with this by caching descriptors in the active snapshot. So those two things would get the same partition descriptor. There's no

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

On Mon, Oct 29, 2018 at 12:04 PM chenhj wrote: > #4 0x007095ac in LWLockAcquire (lock=0x2aaab4009564, > mode=LW_EXCLUSIVE) at lwlock.c:1233 > #5 0x00490a32 in ginStepRight (buffer=6713826, index= out>, lockmode=lockmode@entry=2) at ginbtree.c:174 > #6

Re: jsonpath

On 11/6/18 4:48 PM, Tomas Vondra wrote: > On 11/6/18 3:31 PM, Nikita Glukhov wrote: >> On 29.10.2018 2:20, Tomas Vondra wrote:> >> >> ... >>> >>> 9) It's generally a good idea to make the individual pieces committable >>> separately, but that means e.g. the regression tests have to pass after

Re: jsonpath

BTW is the v19 really just a rebase of the preceding version? I'm asking because v18 was adding two types into pg_type.dat, namely jsonpath (6050) and _jsonpath (6051), while v19 only adds jsonpath (6050). I've noticed because v18 was missing a comma between the two entries, which I'd say is a

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On 8 November 2018 at 15:01, Robert Haas wrote: > Honestly, I *think* that the reason that find_all_inheritors() call is > there is because I had the idea that it was important to try to lock > partition hierarchies in the same order in all cases so as to avoid > spurious deadlocks. However, I

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On 8 November 2018 at 05:05, Robert Haas wrote: > That seems OK at present, because no new partitions can have appeared > since ExecSetupPartitionTupleRouting() acquired locks. But if we > allow new partitions to be added with only ShareUpdateExclusiveLock, > then I think there would be a

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

On Mon, Oct 29, 2018 at 12:04 PM chenhj wrote: > ## stack of autovacuum:Acquire lock 0x2aaab670dfe4 and hold 0x2aaab4009564 > -- > (gdb) bt > #0 0x7fe11552379b in do_futex_wait.constprop.1 () from > /lib64/libpthread.so.0 > #1

Re: fix psql \conninfo & \connect when using hostaddr

On Fri, Oct 26, 2018 at 9:54 AM Fabien COELHO wrote: > About updating psql's behavior, without this patch: > >sh> psql "host=foo hostaddr=127.0.0.1" > >psql> \conninfo >You are connected to database "fabien" as user "fabien" on host "foo" at > port "5432". > # NOPE, I'm really

Re: Tid scan improvements

On Tue, 6 Nov 2018 at 16:52, Alvaro Herrera wrote: > On 2018-Nov-06, David Rowley wrote: > > 14. we pass 'false' to what? > > > > + * save the tuple and the buffer returned to us by the access methods in > > + * our scan tuple slot and return the slot. Note: we pass 'false' because > > + *

Re: PostgreSQL Limits and lack of documentation about them.

On Tue, Nov 6, 2018 at 6:01 AM John Naylor wrote: > On 11/1/18, David Rowley wrote: > > I've attached an updated patch, again it's just intended as an aid for > > discussions at this stage. Also included the rendered html. > > Looks good so far. Based on experimentation with toasted columns, it

Should new partitions inherit their tablespace from their parent?

Dear Hackers, I've just read the thread in [1] where there was a discussion on a bug fix regarding index partitions not being created in the same tablespace as the partitioned index was created. One paragraph that stood out when reading the thread was: On 8 November 2018 at 09:00, Robert Haas

RE: Small performance tweak to run-time partition pruning

On Mon, Oct 22, 2018 at 8:31 PM, David Rowley wrote: > On 18 October 2018 at 16:13, Imai, Yoshikazu > wrote: > > The patch improves the performance about 1.3% which is less than > > David's result, but it seems still improves the performance. > > Thanks for doing these benchmarks. > > The

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

On Wed, Nov 7, 2018 at 11:03 PM Etsuro Fujita wrote: > (2018/11/07 9:22), Kyotaro HORIGUCHI wrote: > > At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro > > Fujita wrote > > in<5be18409.2070...@lab.ntt.co.jp> > >> (2018/11/06 12:53), Kyotaro HORIGUCHI wrote: > >>> even if it comes from another pipe,

Re: Connections hang indefinitely while taking a gin index's LWLock buffer_content lock

On Wed, Nov 7, 2018 at 5:46 PM Peter Geoghegan wrote: > I think that you have to be doing a multi-level delete for a deadlock > to take place, which isn't particularly likely to coincide with a > concurrent insertion in general. That may explain why it's taken a > year to get a high-quality bug

Re: Calculate total_table_pages after set_base_rel_sizes()

On 8 November 2018 at 06:17, Tom Lane wrote: > Pushed with cosmetic adjustments. Thanks for adjusting and pushing. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

Re: pread() and pwrite()

On Thu, Nov 8, 2018 at 4:27 AM Andrew Dunstan wrote: > On 11/7/18 10:05 AM, Jesper Pedersen wrote: > > On 11/7/18 9:30 AM, Tom Lane wrote: > >> I'm confused by this. Surely the pwrite-based code is writing > >> exactly the > >> same data as before. Do we have to conclude that valgrind is > >>

Inadequate executor locking of indexes

I discovered that it's possible to trigger relation_open's new assertion about having a lock on the relation by the simple expedient of running the core regression tests with plan_cache_mode = force_generic_plan. (This doesn't give me a terribly warm feeling about how thoroughly we've exercised

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Wed, Nov 7, 2018 at 7:06 PM David Rowley wrote: > While the find_all_inheritors() call is something I'd like to see > gone, I assume it was done that way since an UPDATE might route a > tuple to a partition that there is no subplan for and due to INSERT > with VALUES not having any

Re: POC: Cleaning up orphaned files using undo logs

On Tue, Nov 6, 2018 at 12:42 AM Kuntal Ghosh wrote: > On Thu, Nov 1, 2018 at 8:53 AM Thomas Munro > wrote: > > It passes make check on Unix and Windows, though currently it's > > failing some of the TAP tests for reasons I'm looking into (possibly > > due to bugs in the lower level patches, not

Re: [HACKERS] [PATCH] Generic type subscripting

st 7. 11. 2018 v 19:35 odesílatel Dmitry Dolgov <9erthali...@gmail.com> napsal: > > On Wed, 7 Nov 2018 at 17:09, Pavel Stehule > wrote: > > > > I don't agree. If we use a same syntax for some objects types, we > should to enforce some consistency. > > Just to make it clear, consistency between

Re: Postgres, fsync, and OSs (specifically linux)

On Fri, Oct 19, 2018 at 6:42 PM Craig Ringer wrote: > On Fri, 19 Oct 2018 at 07:27, Thomas Munro > wrote: >> 2. I am +1 on back-patching Craig's PANIC-on-failure logic. Doing >> nothing is not an option I like. I have some feedback and changes to >> propose though; see attached. > > Thanks

Re: PostgreSQL Limits and lack of documentation about them.

On 8 November 2018 at 10:02, Robert Haas wrote: > IMHO, documenting that you can get up to 1600 integer columns but only > 1002 bigint columns doesn't really help anybody, because nobody has a > table with only one type of column, and people usually want to have > some latitude to run ALTER TABLE

Adding a TAP test checking data consistency on standby with minRecoveryPoint

Hi all, While working on a fix for c186ba13 which fixes the way minRecoveryPoint is updated for other processes than the startup process, I was struggling about being able to get that into a reproducible test case. I have been thinking what Andrew Gierth has mentioned yesterday, and roughly

Re: file cloning in pg_upgrade and CREATE DATABASE

On Wed, Nov 07, 2018 at 06:42:00PM +0100, Peter Eisentraut wrote: > -n is often used for something like "dry run", so it didn't go for that > here. I suspect the cloning will remain a marginal option for some > time, so having only a long option is acceptable. Good point. I didn't consider

Re: jsonpath

Tomas Vondra writes: > BTW is the v19 really just a rebase of the preceding version? > I'm asking because v18 was adding two types into pg_type.dat, namely > jsonpath (6050) and _jsonpath (6051), while v19 only adds jsonpath > (6050). I haven't looked at this patch, but manual generation of

Re: New function pg_stat_statements_reset_query() to reset statistics of a specific query

On Sun, Nov 4, 2018 at 6:37 AM Haribabu Kommi wrote: > > On Sun, Nov 4, 2018 at 11:17 AM Michael Paquier wrote: >> >> On Sat, Nov 03, 2018 at 03:56:14PM +0530, Amit Kapila wrote: >> > Before trying out any solution or deciding which is better, I think we >> > want to understand why the

Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint

On Thu, Nov 08, 2018 at 06:00:29AM +, Andrew Gierth wrote: > I think it would be nice to have a test that didn't rely on that, too. Yes, I don't disagree with you and I thought about it. Fetching the value from the control file is easy, doing the comparison between two LSNs is also simple by

Re: PostgreSQL Limits and lack of documentation about them.

On 11/8/18, David Rowley wrote: > On 8 November 2018 at 10:02, Robert Haas wrote: >> It might be useful for some users to explain that certain things will >> should work for values < X, may work for values between X and Y, and >> will definitely not work above Y. Or maybe we can provide a

Re: csv format for psql

On Wed, Nov 07, 2018 at 05:36:54PM +0100, Daniel Verite wrote: > I guess it could go into a #define in psql/settings.h, along with > these: > #define DEFAULT_FIELD_SEP "|" > #define DEFAULT_RECORD_SEP "\n" Yes. > Yes, since we support column names with embedded newlines (even > though it's hard

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/07 20:46, David Rowley wrote: > On 5 November 2018 at 20:17, Amit Langote > wrote: >> On 2018/11/04 19:07, David Rowley wrote: >>> Perhaps a better design would be to instead of having random special >>> partitioned-table-only fields in ResultRelInfo, just have an extra >>> struct

Re: Should new partitions inherit their tablespace from their parent?

On Thu, Nov 08, 2018 at 12:50:40PM +1300, David Rowley wrote: > How about we record the tablespace option for the partitioned table in > reltablespace instead of saving it as 0. Newly created partitions > which don't have a TABLESPACE mentioned in the CREATE TABLE command > should be created in

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On 2018/11/08 11:01, Robert Haas wrote: > On Wed, Nov 7, 2018 at 7:06 PM David Rowley > wrote: >> While the find_all_inheritors() call is something I'd like to see >> gone, I assume it was done that way since an UPDATE might route a >> tuple to a partition that there is no subplan for and due to

Re: move PartitionBoundInfo creation code

On 2018/11/08 11:48, Michael Paquier wrote: >>> Thinking crazy, we could also create a subfolder partitioning/bounds/ >>> which includes three files with this refactoring:x >>> - range.c >>> - values.c >>> - hash.c >>> Then we keep partbounds.c which is the entry point used by partcache.c, >>> and

Re: ON COMMIT actions and inheritance

Hi, Thank you updating the patch and adding notes to the documentation about the points I raised. On 2018/11/07 9:53, Michael Paquier wrote: > On Tue, Nov 06, 2018 at 07:04:17PM +0900, Amit Langote wrote: >> Agree with keeping it simple. Maybe, we could (should?) document that the >> only ON

Re: move PartitionBoundInfo creation code

On Wed, Nov 07, 2018 at 12:04:27PM -0300, Alvaro Herrera wrote: > On 2018-Nov-07, Michael Paquier wrote: > This is interesting. I don't think the current interface is so bad that > we can't make a few tweaks later; IOW let's focus on the current patch > for now, and we can improve later. You

Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint

> "Michael" == Michael Paquier writes: Michael> I have also been trying to shape that into a TAP test which Michael> can be added into the in-core recovery test suite, and it Michael> happens that the part which scans if all the pages of a Michael> relation are not newer than what

Re: move PartitionBoundInfo creation code

On 2018/11/08 0:04, Alvaro Herrera wrote: >> On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote: >>> I think we can design the interface of partition_bounds_create such that >>> it returns information needed to re-arrange OIDs to be in the canonical >>> partition bound order, so the

Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint

On Thu, Nov 08, 2018 at 05:04:35AM +, Andrew Gierth wrote: > How? It's OK (and normal) for in-core pages to have newer LSNs than > minRecoveryPoint, it's only on-disk pages that must not be more recent > than that. And pageinspect will show the in-core page... If the standby is stopped

Re: Removing unneeded self joins

On 19 October 2018 at 01:47, Alexander Kuzmenkov wrote: > Here is a version that compiles. I had a quick read through this and I think its missing about a 1-page comment section detailing when we can and when we cannot remove these self joins, and what measures we must take when we do remove

Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint

> "Michael" == Michael Paquier writes: >> How? It's OK (and normal) for in-core pages to have newer LSNs than >> minRecoveryPoint, it's only on-disk pages that must not be more >> recent than that. And pageinspect will show the in-core page... Michael> If the standby is stopped cleanly

Re: move PartitionBoundInfo creation code

On 2018/11/08 12:59, Amit Langote wrote: > It might be okay to split the big switch in partition_bounds_create() into > different functions for different partitioning methods for clarity as you > say, but let's avoid creating new files for range, list, and hash. > > I will post an updated patch

Re: file cloning in pg_upgrade and CREATE DATABASE

On 07/11/2018 19:03, Tom Lane wrote: > Peter Eisentraut writes: >> Committed, thanks. > > It seems unfortunate that there is no test coverage in the committed > patch. I realize that it may be hard to test given the filesystem > dependency, but how will we know if it works at all? You can use

Connection limit doesn't work for superuser

Connection limit doesn't work for superuser Hi hackers! It would be nice if ALTER USER ... WITH CONNECTION LIMIT will work for superuser. It would protect against connection leaks. e.g. we have two superusers, one of them reached connection limit but not max_connections, the other is still

Re: Connection limit doesn't work for superuser

Hi! > 7 нояб. 2018 г., в 11:48, Evgeniy Efimkin написал(а): > It would be nice if ALTER USER ... WITH CONNECTION LIMIT will work for > superuser. It would protect against connection leaks. e.g. we have two > superusers, one of them reached connection limit but not max_connections, the > other

Re: [Patch] pg_rewind: options to use restore_command from recovery.conf or command line

On 30.10.2018 06:01, Michael Paquier wrote: On Mon, Oct 29, 2018 at 12:09:21PM +0300, Alexey Kondratov wrote: Currently in the patch, with dry-run option (-n) pg_rewind only fetches missing WALs to be able to build file map, while doesn't touch any data files. So I guess it behaves exactly as

RE: Issue with v11.0 within jsonb_plperl tests in 32bit on AIX

Hi Alvaro, Thanks for your help. Here is the regression.diffs file. About the root cause, I noticed that, for the 2nd error: < ERROR: cannot convert infinity to jsonb < CONTEXT: PL/Perl function "roundtrip" --- >

Re: Connection slots reserved for replication

On Tue, Nov 6, 2018 at 9:16 PM Kyotaro HORIGUCHI wrote: > > Hello. Thank you for the new version. > > At Thu, 1 Nov 2018 11:58:52 +0100, Alexander Kukushkin > wrote in > > Hi, > > > > Attached rebased version patch to the current HEAD and created commit fest > > entry > > On Fri, 21 Sep 2018

Re: pread() and pwrite()

Hi Thomas, On 11/6/18 4:04 PM, Thomas Munro wrote: On Wed, Nov 7, 2018 at 4:42 AM Jesper Pedersen Thanks! Pushed. I'll keep an eye on the build farm to see if anything breaks on Cygwin or some other frankenOS. There is [1] on Andres' skink setup. Looking. [1]

Re: BUG #15449: file_fdw using program cause exit code error when using LIMIT

(2018/11/07 9:22), Kyotaro HORIGUCHI wrote: At Tue, 06 Nov 2018 21:07:37 +0900, Etsuro Fujita wrote in<5be18409.2070...@lab.ntt.co.jp> (2018/11/06 12:53), Kyotaro HORIGUCHI wrote: At Fri, 02 Nov 2018 22:05:36 +0900, Etsuro Fujita wrote in<5bdc4ba0.7050...@lab.ntt.co.jp> (2018/10/29 15:58),

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 5 November 2018 at 20:17, Amit Langote wrote: > On 2018/11/04 19:07, David Rowley wrote: >> Perhaps a better design would be to instead of having random special >> partitioned-table-only fields in ResultRelInfo, just have an extra >> struct there that contains the extra partition information

RE: Performance improvements of INSERTs to a partitioned table

AFAIK, When CREATE INDEX on a partition and INSERT to a parent table are executed at the same time, this patch causes deadlock. * partitions information Partition key: RANGE (a) Partitions: a_1 FOR VALUES FROM (1) TO (100), a_2 FOR VALUES FROM (100) TO (200) T1: create index a_1_ix

Re: csv format for psql

Bonjour Michaël, First, it seems to me that it is necessary to overcomplicate the interface of psql for that. Most of the other formats don't have their own switch, and it is perfectly possible to use CSV format with just --pset=format=csv. Although this work, it is not very user friendly

RE: [Bug Fix]ECPG: cancellation of significant digits on ECPG

From: Dmitry Dolgov [mailto:9erthali...@gmail.com] >Also what's strange for me is that after applying your patches I still got the >same output, not sure why: Hmm... In my environment, the output was changed. I also updated regression test and cfbot.cputube.org reports no problem now. Do you

Re: csv format for psql

On Tue, Nov 06, 2018 at 02:57:15PM +0100, Daniel Verite wrote: > Here's a rebased version following these changes. Thanks for doing a rebase. First, it seems to me that it is necessary to overcomplicate the interface of psql for that. Most of the other formats don't have their own switch, and

Re: pread() and pwrite()

On 11/7/18 7:26 AM, Jesper Pedersen wrote: Hi Thomas, On 11/6/18 4:04 PM, Thomas Munro wrote: On Wed, Nov 7, 2018 at 4:42 AM Jesper Pedersen Thanks!  Pushed.  I'll keep an eye on the build farm to see if anything breaks on Cygwin or some other frankenOS. There is [1] on Andres' skink

Re: valgrind on initdb

On 11/7/18, Jesper Pedersen wrote: > Hi, > > While looking at [1] (included in 23315.log) there are other warnings as > well. Perhaps it's worth revisiting to make debugging easier, but right now initdb.c has this comment: * Note: * The program has some memory leakage - it isn't worth

Re: valgrind on initdb

On 11/7/18 8:08 AM, Jesper Pedersen wrote: While looking at [1] (included in 23315.log) there are other warnings as well. On 77366d90. Best regards,  Jesper

Re: fix psql \conninfo & \connect when using hostaddr

Hello all, On 07.11.2018 16:23, Pavel Stehule wrote: pá 26. 10. 2018 v 15:55 odesílatel Fabien COELHO > napsal: > > This is a follow-up to another patch I posted about libpq confusing > documentation & psql resulting behavior under host/hostaddr settings. >

valgrind on initdb

Hi, While looking at [1] (included in 23315.log) there are other warnings as well. I ran with valgrind --leak-check=full --show-leak-kinds=all --gen-suppressions=all --suppressions=/path/to/postgresql/src/tools/valgrind.supp --time-stamp=yes --log-file=/tmp/valgrind/%p.log

Re: fix psql \conninfo & \connect when using hostaddr

Hi pá 26. 10. 2018 v 15:55 odesílatel Fabien COELHO napsal: > > Hello, > > This is a follow-up to another patch I posted about libpq confusing > documentation & psql resulting behavior under host/hostaddr settings. > > Although the first mostly documentation patch did not gather much >

Re: pread() and pwrite()

Hi, On 11/7/18 7:26 AM, Jesper Pedersen wrote: On 11/6/18 4:04 PM, Thomas Munro wrote: On Wed, Nov 7, 2018 at 4:42 AM Jesper Pedersen Thanks!  Pushed.  I'll keep an eye on the build farm to see if anything breaks on Cygwin or some other frankenOS. There is [1] on Andres' skink setup.

Re: valgrind on initdb

On 11/7/18 2:47 PM, John Naylor wrote: > On 11/7/18, Jesper Pedersen wrote: >> Hi, >> >> While looking at [1] (included in 23315.log) there are other warnings as >> well. > > Perhaps it's worth revisiting to make debugging easier, but right now > initdb.c has this comment: > > * Note: > *

Re: plruby: rb_iterate symbol clash with libruby.so

On Tuesday, November 6, 2018 7:28:21 PM CET Tom Lane wrote: > I wrote: > > Yeah. The long and short of this is that we're trampling on namespace > > that reasonably belongs to Ruby --- if they had some functions named > > "pg_something" and complained about a collision with libpq, would we > >

Re: Support custom socket directory in pg_upgrade

> On 6 Nov 2018, at 09:19, Thomas Munro wrote: > > On Wed, Oct 10, 2018 at 9:27 AM Daniel Gustafsson > wrote: >>> On 9 Oct 2018, at 16:22, Tom Lane wrote: >>> Daniel Gustafsson writes: Having hit the maximum socketdir length error a number of times in

Re: Connection limit doesn't work for superuser

On Wed, Nov 7, 2018 at 7:20 AM Andrey Borodin wrote: > >These clauses determine whether the new role is a “superuser”, who can > >override all access restrictions within the database. > Do we consider connection limit "access restriction"? Superuser can avoid > setting his connection limit if

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Tue, Nov 6, 2018 at 10:18 PM Alvaro Herrera wrote: > > > Throw tuples destined for that partition away? > > Surely not. (/me doesn't beat straw men anyway.) > > Hmm, apparently this can indeed happen with my patch :-( D'oh. This is a hard problem, especially the part of it that involves

Fedora 29 vs linux collation tests

Yesterday I did a long overdue upgrade to the machine that runs buildfarm animal crake. After some hiccups it's all working, except for the linux utf8 collation tests. See where you can see this:

Re: move PartitionBoundInfo creation code

On 2018-Nov-07, Michael Paquier wrote: > On Wed, Nov 07, 2018 at 03:34:38PM +0900, Amit Langote wrote: > > On 2018/11/05 16:21, Michael Paquier wrote: > >> On Thu, Nov 01, 2018 at 01:03:00PM +0900, Amit Langote wrote: > >>> Done a few moments ago. :) > >> > >> From the file size this move is

Re: Connection limit doesn't work for superuser

What about LOGIN option? It is a similar access restriction, but it works for superuser. =# create role nologin_role superuser nologin unencrypted password '1234'; CREATE ROLE Time: 1.230 ms ~ $ psql postgres -U nologin_role -h localhost Password for user nologin_role: psql: FATAL: role

Re: pread() and pwrite()

Hi Tom, On 11/7/18 9:30 AM, Tom Lane wrote: I'm confused by this. Surely the pwrite-based code is writing exactly the same data as before. Do we have to conclude that valgrind is complaining about passing uninitialized data to pwrite() when it did not complain about exactly the same thing for

Re: [HACKERS] [PATCH] Generic type subscripting

> On Fri, 12 Oct 2018 at 07:52, Pavel Stehule wrote: > >> > postgres=# insert into test(v) values( '[]'); >> > INSERT 0 1 >> > postgres=# update test set v[1000] = 'a'; >> > UPDATE 1 >> > postgres=# update test set v[1000] = 'a'; >> > UPDATE 1 >> > postgres=# update test set v[1000] = 'a'; >> >

Re: plruby: rb_iterate symbol clash with libruby.so

Pavel Raiskup writes: > On Tuesday, November 6, 2018 7:28:21 PM CET Tom Lane wrote: >> Done. I realized that the immediate problem, rb_iterate(), was only >> added as of PG v10, which may explain why we hadn't heard complaints >> about this till now. So I've made the change only as far back as

Re: pread() and pwrite()

Andrew Dunstan writes: > On 11/7/18 7:26 AM, Jesper Pedersen wrote: >> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2018-11-07%2001%3A01%3A01 > And lousyjack, which uses a slightly different way of calling valgrind, > and thus got past initdb, found a bunch more: >

Re: valgrind on initdb

On 11/7/18 9:11 AM, Tomas Vondra wrote: On 11/7/18 2:47 PM, John Naylor wrote: On 11/7/18, Jesper Pedersen wrote: Hi, While looking at [1] (included in 23315.log) there are other warnings as well. Perhaps it's worth revisiting to make debugging easier, but right now initdb.c has this

Re: Connection limit doesn't work for superuser

Robert Haas writes: > I don't think we should consider something that prevents you from > connecting to the database to be in the same category as something > that limits what you can do once you are connected. IOW, +1 to the > original proposal from me. I'd vote against. I think there are way

Re: pread() and pwrite()

On 11/7/18 9:30 AM, Tom Lane wrote: Andrew Dunstan writes: On 11/7/18 7:26 AM, Jesper Pedersen wrote: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink=2018-11-07%2001%3A01%3A01 And lousyjack, which uses a slightly different way of calling valgrind, and thus got past initdb,

Re: partitioned indexes and tablespaces

On 2018-11-07 11:19:53 -0500, Robert Haas wrote: > On Wed, Nov 7, 2018 at 10:46 AM Alvaro Herrera > wrote: > > I think 11.0 is ready for testing that a migration from a production > > running 10.x, but not for just blindly migrating. If you wanted to take > > such a leap of faith, surely you'd

Re: pread() and pwrite()

On 11/7/18 10:05 AM, Jesper Pedersen wrote: Hi Tom, On 11/7/18 9:30 AM, Tom Lane wrote: I'm confused by this.  Surely the pwrite-based code is writing exactly the same data as before.  Do we have to conclude that valgrind is complaining about passing uninitialized data to pwrite() when it

Re: plruby: rb_iterate symbol clash with libruby.so

On Wednesday, November 7, 2018 3:25:31 PM CET Tom Lane wrote: > Pavel Raiskup writes: > > On Tuesday, November 6, 2018 7:28:21 PM CET Tom Lane wrote: > >> Done. I realized that the immediate problem, rb_iterate(), was only > >> added as of PG v10, which may explain why we hadn't heard complaints

Re: partitioned indexes and tablespaces

On 2018-Nov-04, Michael Paquier wrote: > On Sat, Nov 03, 2018 at 12:30:15PM -0700, Andres Freund wrote: > > On 2018-11-03 16:24:28 -0300, Alvaro Herrera wrote: > >> On 2018-Nov-03, Robert Haas wrote: > >>> Well, you've guaranteed that already. Now 11 will be different from > >>> 11.1, and tables

Re: ATTACH/DETACH PARTITION CONCURRENTLY

On Tue, Nov 6, 2018 at 5:09 PM Robert Haas wrote: > - get_partition_dispatch_recurse and ExecCreatePartitionPruneState > both call RelationGetPartitionDesc. Presumably, this means that if > the partition descriptor gets updated on the fly, the tuple routing > and partition dispatch code could

  1   2   >