Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Sun, Apr 9, 2017 at 11:17 PM, Noah Misch wrote: > The above-described topic is currently a PostgreSQL 10 open item. I have committed the patch. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Sat, Mar 25, 2017 at 09:55:21PM +1300, Thomas Munro wrote: > On Sat, Mar 25, 2017 at 6:04 PM, Amit Kapila wrote: > > On Tue, Mar 21, 2017 at 5:51 PM, Dilip Kumar wrote: > >> On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro > >>

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Sat, Mar 25, 2017 at 2:25 PM, Thomas Munro wrote: >>> I think in this area we need more testing, reason these are not tested >>> properly because these are not the natural case for parallel bitmap. >>> I think in next few days I will test more such cases by

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Sat, Mar 25, 2017 at 6:04 PM, Amit Kapila wrote: > On Tue, Mar 21, 2017 at 5:51 PM, Dilip Kumar wrote: >> On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro >> wrote: >>> I noticed a failure in the inet.sql test while

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Tue, Mar 21, 2017 at 5:51 PM, Dilip Kumar wrote: > On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro > wrote: >> I noticed a failure in the inet.sql test while running the regression >> tests with parallelism cranked up, and can reproduce it

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Wed, Mar 22, 2017 at 5:38 AM, Thomas Munro wrote: > Isn't that one row short? What happened to this one? > > 10.0.0.0/8 | 10::/8 Actually, In my last test I did not connect to regression database, I have simply taken table and the few rows from

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Wed, Mar 22, 2017 at 1:21 AM, Dilip Kumar wrote: > postgres=# SELECT * FROM inet_tbl WHERE i <> '192.168.1.0/24'::cidr > ORDER BY i; > c |i > +-- > 10.0.0.0/8 | 9.1.2.3/8 > 10.0.0.0/8 |

Re: [HACKERS] Problem in Parallel Bitmap Heap Scan?

On Tue, Mar 21, 2017 at 4:47 PM, Thomas Munro wrote: > I noticed a failure in the inet.sql test while running the regression > tests with parallelism cranked up, and can reproduce it interactively > as follows. After an spgist index is created and the plan changes

[HACKERS] Problem in Parallel Bitmap Heap Scan?

Hi, I noticed a failure in the inet.sql test while running the regression tests with parallelism cranked up, and can reproduce it interactively as follows. After an spgist index is created and the plan changes to the one shown below, the query returns no rows. regression=# set

Re: [HACKERS] Problem in PostgresSQL Configuration with YII 1 & Wordpress

On 24 July 2016 at 02:20, Jyoti Sharma wrote: > Hi Team, > > Currently we have a project running with MySQL with YII & Wordpress, Now i > want to change the Database from MYSQL to PostgreSQL. > Hi. The pgsql-hackers mailing list is for development of PostgreSQL its

[HACKERS] Problem in PostgresSQL Configuration with YII 1 & Wordpress

Hi Team, Currently we have a project running with MySQL with YII & Wordpress, Now i want to change the Database from MYSQL to PostgreSQL. Please put your inline comments below. *[JS:] *Is there any way we can convert MYSQL queries to PostreSQL Queries? *Your Comment : ?* *[JS:] *Is there any

Re: [HACKERS] Problem with dumping bloom extension

* Noah Misch (n...@leadboat.com) wrote: > Yep, pretty much that. CLOSE_WAIT is for performance defects, race > conditions, and other defects where a successful fix is difficult to verify > beyond reasonable doubt. Other things can move directly to "resolved". I > don't mind if practice diverges

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 07, 2016 at 03:23:46PM -0400, Robert Haas wrote: > On Tue, Jun 7, 2016 at 2:40 PM, Peter Eisentraut > wrote: > > On 6/7/16 11:16 AM, Stephen Frost wrote: > >> > >> Moved to CLOSE_WAIT. > > > > Could you add an explanation on the wiki page about what

Re: [HACKERS] Problem with dumping bloom extension

* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 6/7/16 11:16 AM, Stephen Frost wrote: > >Moved to CLOSE_WAIT. > > Could you add an explanation on the wiki page about what this section means? I understood it to simply be a step on the way to being resolved- that is, everything

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 2:40 PM, Peter Eisentraut wrote: > On 6/7/16 11:16 AM, Stephen Frost wrote: >> >> Moved to CLOSE_WAIT. > > Could you add an explanation on the wiki page about what this section means? Noah created that section. My interpretation is that

Re: [HACKERS] Problem with dumping bloom extension

On 6/7/16 11:16 AM, Stephen Frost wrote: Moved to CLOSE_WAIT. Could you add an explanation on the wiki page about what this section means? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via

Re: [HACKERS] Problem with dumping bloom extension

* Noah Misch (n...@leadboat.com) wrote: > The above-described topic is currently a PostgreSQL 9.6 open item. Stephen, > since you committed the patch believed to have created it, you own this open > item. If some other commit is more relevant or if this does not belong as a > 9.6 open item,

Re: [HACKERS] Problem with dumping bloom extension

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > Stephen, are you working on a patch or should I get one out of my > pocket? That's something we should get fixed quickly. We need as well > to be careful with the support for COMMENT with access methods, the > current consensus on

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 8:10 PM, Robert Haas wrote: > On Mon, Jun 6, 2016 at 5:55 PM, Michael Paquier > wrote: >>> It seems important to get this fixed. I added it to the open items list. >> >> I added already it as " Access methods created with

Re: [HACKERS] Problem with dumping bloom extension

On Mon, Jun 6, 2016 at 5:55 PM, Michael Paquier wrote: >> It seems important to get this fixed. I added it to the open items list. > > I added already it as " Access methods created with extensions are > dumped individually ". That's not specific to bloom. Oh, sorry,

Re: [HACKERS] Problem with dumping bloom extension

On Fri, Jun 03, 2016 at 12:31:44PM -0400, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > > > If a database with the bloom extension installed is dumped and restored, > > > there's an error with

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 6:55 AM, Michael Paquier wrote: > On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote: >> On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote: Stephen, something is smelling wrong in

Re: [HACKERS] Problem with dumping bloom extension

On Tue, Jun 7, 2016 at 12:01 AM, Robert Haas wrote: > On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote: >>> Stephen, something is smelling wrong in checkExtensionMembership() >>> since 5d58999, an access method does not have ACLs and I would have

Re: [HACKERS] Problem with dumping bloom extension

On Fri, Jun 3, 2016 at 12:31 PM, Stephen Frost wrote: >> Stephen, something is smelling wrong in checkExtensionMembership() >> since 5d58999, an access method does not have ACLs and I would have >> expected that when this routine is invoked in >> selectDumpableAccessMethod()

Re: [HACKERS] Problem with dumping bloom extension

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > > If a database with the bloom extension installed is dumped and restored, > > there's an error with the access method creation: > > > > createdb bloomtest > > psql

Re: [HACKERS] Problem with dumping bloom extension

On Fri, Jun 3, 2016 at 8:57 PM, Thom Brown wrote: > If a database with the bloom extension installed is dumped and restored, > there's an error with the access method creation: > > createdb bloomtest > psql -c 'CREATE EXTENSION bloom;' bloomtest > pg_dump -d bloomtest >

[HACKERS] Problem with dumping bloom extension

Hi, If a database with the bloom extension installed is dumped and restored, there's an error with the access method creation: createdb bloomtest psql -c 'CREATE EXTENSION bloom;' bloomtest pg_dump -d bloomtest > ~/tmp/bloom.sql createdb bloomtest2 psql -d bloomtest2 -f ~/tmp/bloom.sql The

Re: [HACKERS] problem with precendence order in JSONB merge operator

Please don't top-post. On Tuesday, March 22, 2016, Peter Krauss wrote: > Subjective notes to contextualize (try to explain on bad-English) my > "precedence order" and JSONB visions: > > JSON datatype is perfect as workaround, and for many simple and less > exigent

Re: [HACKERS] problem with precendence order in JSONB merge operator

Subjective notes to contextualize (try to explain on bad-English) my "precedence order" and JSONB visions: JSON datatype is perfect as workaround, and for many simple and less exigent applications. JSONB is the "first class" datatype for user community, we expected years (!) for it ... Need some

Re: [HACKERS] problem with precendence order in JSONB merge operator

On Tue, Mar 22, 2016 at 1:52 PM, Peter Krauss wrote: > Seems that parser not using precedence ideal order, and that casting > obligation losts performance. > > The first problem is self-evident in this example: > > SELECT '{"x":1}'::jsonb || (('{"A":{"y":2}}'::jsonb)->'A') >

[HACKERS] problem with precendence order in JSONB merge operator

Seems that parser not using precedence ideal order, and that casting obligation losts performance. The first problem is self-evident in this example: SELECT '{"x":1}'::jsonb || (('{"A":{"y":2}}'::jsonb)->'A') -- it is ok, expected result with (x,y) SELECT '{"x":1}'::jsonb ||

Re: [HACKERS] problem with msvc linker - cannot build orafce

2015-11-23 21:14 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > I am trying to build Orafce and I have problem due access to exported > > variable session_timezone. > > Any idea what can be broken? > > Lack of PGDLLIMPORT on the extern declaration,

Re: [HACKERS] problem with msvc linker - cannot build orafce

2015-11-24 11:33 GMT+01:00 Kisung Kim : > 2015-11-24 8:12 GMT+09:00 Chapman Flack : > >> On 11/23/15 15:14, Tom Lane wrote: >> > Lack of PGDLLIMPORT on the extern declaration, no doubt. >> > >> > The fact that we've not heard this before implies that

Re: [HACKERS] problem with msvc linker - cannot build orafce

Dne 24. 11. 2015 15:44 napsal uživatel "Chapman Flack" < c...@anastigmatix.net>: > > On 11/24/2015 05:33 AM, Kisung Kim wrote: > > 2015-11-24 8:12 GMT+09:00 Chapman Flack : > >> On 11/23/15 15:14, Tom Lane wrote: > >>> Lack of PGDLLIMPORT on the extern declaration, no doubt.

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 24 November 2015 at 07:12, Chapman Flack wrote: > > What I (think I) took away from it was: > > 1. Un-PGDLLIMPORTed references to global *functions* work ok. > Maybe they are thunked and a little less efficient, but they work. > > 2. Un-PGDLLIMPORTed references to

Re: [HACKERS] problem with msvc linker - cannot build orafce

> > > I don't think that's necessary, per above. You just have to access the > vars via pointer indirection always, so long as *any* Pg version you > support has ever lacked dllexport or DEF entry, so you can't dllimport the > var. > > You could enable direct dllimport if PG_VERSION_NUM shows

Re: [HACKERS] problem with msvc linker - cannot build orafce

Craig Ringer writes: > Actually, if __declspec(dllexport) or a .DEF entry was added in, say, > 9.4.5, you could probably just: > #if PG_VERSION_NUM < 90405 > extern int* log_min_messages_p; > #define log_min_messages (*log_min_messages_p) > #endif > after including all

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 25 November 2015 at 13:36, Tom Lane wrote: > Craig Ringer writes: > > Actually, if __declspec(dllexport) or a .DEF entry was added in, say, > > 9.4.5, you could probably just: > > > #if PG_VERSION_NUM < 90405 > > extern int* log_min_messages_p; > >

Re: [HACKERS] problem with msvc linker - cannot build orafce

2015-11-24 8:12 GMT+09:00 Chapman Flack : > On 11/23/15 15:14, Tom Lane wrote: > > Lack of PGDLLIMPORT on the extern declaration, no doubt. > > > > The fact that we've not heard this before implies that either nobody has > > ever tried to use orafce on Windows, or it only

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 11/24/2015 05:33 AM, Kisung Kim wrote: > 2015-11-24 8:12 GMT+09:00 Chapman Flack : >> On 11/23/15 15:14, Tom Lane wrote: >>> Lack of PGDLLIMPORT on the extern declaration, no doubt. >> > Actually, we encountered the situation before couple of months. > A client wanted to

[HACKERS] problem with msvc linker - cannot build orafce

Hi I am trying to build Orafce and I have problem due access to exported variable session_timezone. The build fails with message: 1> Creating library C:\Users\Pavel\orafce-VERSION_3_1_2\orafce-VERSION_3_1_2\msvc\/bin/x64/9.4/lib/orafce.lib and object

Re: [HACKERS] problem with msvc linker - cannot build orafce

Pavel Stehule writes: > I am trying to build Orafce and I have problem due access to exported > variable session_timezone. > Any idea what can be broken? Lack of PGDLLIMPORT on the extern declaration, no doubt. The fact that we've not heard this before implies that

Re: [HACKERS] problem with msvc linker - cannot build orafce

On 11/23/15 15:14, Tom Lane wrote: > Pavel Stehule writes: >> I am trying to build Orafce and I have problem due access to exported >> variable session_timezone. >> Any idea what can be broken? > > Lack of PGDLLIMPORT on the extern declaration, no doubt. > > The fact

Re: [HACKERS] Problem with CREATE TABLE ... (LIKE ... INCLUDING INDEXES)

On 14 June 2015 at 04:25, Michael Paquier michael.paqu...@gmail.com wrote: On Sun, Jun 14, 2015 at 11:38 AM, Thom Brown t...@linux.com wrote: As you can see, 3 indexes are missing, which happen to be ones that would duplicate the column definition of another index. Is this intentional? If

Re: [HACKERS] Problem with CREATE TABLE ... (LIKE ... INCLUDING INDEXES)

Thom Brown t...@linux.com writes: The commit refers to duplicate index names, and only for UNIQUE indexes. This behaviour is beyond that. And how does it determine which index to copy? In my example, I placed an index in a different tablespace. That could be on a drive with very different

[HACKERS] Problem with CREATE TABLE ... (LIKE ... INCLUDING INDEXES)

Hi all, I've noticed that LIKE tablename INCLUDING INDEXES skips any indexes that were duplicated. e.g. CREATE TABLE people (id int, alias text); CREATE INDEX idx_people_id_1 ON people (id); CREATE INDEX idx_people_id_2 ON people (id) WHERE id % 2 = 0; CREATE INDEX idx_people_alias_1 ON people

Re: [HACKERS] Problem with CREATE TABLE ... (LIKE ... INCLUDING INDEXES)

On Sun, Jun 14, 2015 at 11:38 AM, Thom Brown t...@linux.com wrote: As you can see, 3 indexes are missing, which happen to be ones that would duplicate the column definition of another index. Is this intentional? If so, shouldn't it be documented behaviour? Looking at the code

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 05/06/2014 02:44 PM, Andres Freund wrote: On 2014-05-05 13:41:00 +0300, Heikki Linnakangas wrote: +/* + * Exit hook to unlock the global transaction entry we're working on. + */ +static void +AtProcExit_Twophase(int code, Datum arg) +{ + /* same logic as abort */ +

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 2014-05-15 17:21:28 +0300, Heikki Linnakangas wrote: Is it guaranteed that all paths have called LWLockReleaseAll() before calling the proc exit hooks? Otherwise we might end up waiting for ourselves... Hmm. AbortTransaction() will release locks before we get here, but the

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/14/2014 11:55 AM, Marko Kreen wrote: On Sun, Apr 13, 2014 at 05:46:20PM -0400, Jan Wieck wrote: On 04/13/14 14:22, Jan Wieck wrote: On 04/13/14 08:27, Marko Kreen wrote: I think you need to do SET_VARSIZE also here. Alternative is to move SET_VARSIZE after sort_snapshot(). And it

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On Thu, May 15, 2014 at 10:38 AM, Andres Freund and...@2ndquadrant.com wrote: shrug. async.c and namespace.c does the same, and it hasn't been a problem. Well, it doesn't seem unreasonable to have C code using PG_ENSURE_ERROR_CLEANUP/PG_END_ENSURE_ERROR_CLEANUP around a 2pc commit to me.

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

Hi, On 2014-05-05 13:41:00 +0300, Heikki Linnakangas wrote: I came up with the attached fix for this. Currently, the entry is implicitly considered dead or unlocked if the locking_xid transaction is no longer active, but this patch essentially turns locking_xid into a simple boolean, and

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 04/14/2014 09:48 PM, Heikki Linnakangas wrote: On 04/14/2014 07:51 PM, Tom Lane wrote: I'd prefer to leave the prepare sequence alone and instead find a way to reject COMMIT PREPARED until after the source transaction is safely clear of the race conditions. The upthread idea of looking at

Re: [HACKERS] Problem with displaying wide tables in psql

On Tue, Apr 29, 2014 at 2:52 AM, Peter Eisentraut pete...@gmx.net wrote: Please fix this compiler warning. I think it came from this patch. Oops, I fixed it in a previous version but didn't notice it had crept back in in the back-and-forth. Will do. -- greg -- Sent via pgsql-hackers

Re: [HACKERS] Problem with displaying wide tables in psql

Please fix this compiler warning. I think it came from this patch. print.c: In function ‘print_aligned_vertical’: print.c:1354:10: error: pointer targets in passing argument 1 of ‘strlen_max_width’ differ in signedness [-Werror=pointer-sign] encoding); ^ print.c:126:12:

Re: [HACKERS] Problem with displaying wide tables in psql

On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: 2014-04-29 5:52 GMT+04:00 Peter Eisentraut pete...@gmx.net: Please fix this compiler warning. I think it came from this patch. print.c: In function 'print_aligned_vertical': print.c:1354:10: error: pointer

Re: [HACKERS] Problem with displaying wide tables in psql

rebased 2014-04-29 7:43 GMT+04:00 Michael Paquier michael.paqu...@gmail.com: On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov sergey.k.murav...@gmail.com wrote: 2014-04-29 5:52 GMT+04:00 Peter Eisentraut pete...@gmx.net: Please fix this compiler warning. I think it came from this

Re: [HACKERS] Problem with displaying wide tables in psql

Greg Stark st...@mit.edu writes: I expect this regression test to fail on platforms that don't support utf-8 client-side (I'm assuming we such things?). I don't have such a platform here and I'm not sure how it would fail so I want to go ahead and apply it and grab the output to add the

Re: [HACKERS] Problem with displaying wide tables in psql

Not sure what other encodings you mean. Psql uses utf8 for the border and the test uses utf8 to test the formatting. I was only anticipating an error on platforms where that didn't work. I would lean towards having it but I'm fine following your judgement, especially given the timing. -- greg

Re: [HACKERS] Problem with displaying wide tables in psql

Greg Stark st...@mit.edu writes: Not sure what other encodings you mean. Psql uses utf8 for the border and the test uses utf8 to test the formatting. I was only anticipating an error on platforms where that didn't work. Well, there are two likely misbehaviors if the regression test is being

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 04/13/2014 11:39 PM, Heikki Linnakangas wrote: However, I just noticed that there's a race condition between PREPARE TRANSACTION and COMMIT/ROLLBACK PREPARED. PostPrepare_Locks runs after the prepared transaction is already marked as fully prepared. That means that by the time we get to

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On Sun, Apr 13, 2014 at 05:46:20PM -0400, Jan Wieck wrote: On 04/13/14 14:22, Jan Wieck wrote: On 04/13/14 08:27, Marko Kreen wrote: I think you need to do SET_VARSIZE also here. Alternative is to move SET_VARSIZE after sort_snapshot(). And it seems the drop-double-txid logic should be

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/2014 05:03 PM, Andres Freund wrote: On 2014-04-12 09:47:24 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 2014-04-14 12:15:30 +0300, Heikki Linnakangas wrote: Hmm. There's a field in GlobalTransactionData called locking_xid, which is used to mark the XID of the transaction that's currently operating on the prepared transaction. At prepare, that ensures that the transaction cannot be committed

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

Heikki Linnakangas hlinnakan...@vmware.com writes: I think we'll need to transfer of the locks earlier, before the transaction is marked as fully prepared. I'll take a closer look at this tomorrow. Here's a patch to do that. It's very straightforward, I just moved the calls to transfer

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 2014-04-14 12:51:02 -0400, Tom Lane wrote: The whole thing feels like we are solving the wrong problem, anyway. IIUC, the complaint arises because we are allowing COMMIT PREPARED to occur before the source transaction has reported successful prepare to its client. Surely that does not need

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

Andres Freund and...@2ndquadrant.com writes: I wonder if the most natural way to express this wouldn't be to have a heavyweight lock for every 2pc xact 'slot'. ResourceOwnerRelease(RESOURCE_RELEASE_LOCKS) should be scheduled correctly to make error handling for this work. That seems like not

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 2014-04-14 13:47:35 -0400, Tom Lane wrote: Andres Freund and...@2ndquadrant.com writes: I wonder if the most natural way to express this wouldn't be to have a heavyweight lock for every 2pc xact 'slot'. ResourceOwnerRelease(RESOURCE_RELEASE_LOCKS) should be scheduled correctly to make

Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 04/14/2014 07:51 PM, Tom Lane wrote: I'd prefer to leave the prepare sequence alone and instead find a way to reject COMMIT PREPARED until after the source transaction is safely clear of the race conditions. The upthread idea of looking at vxid instead of xid might help, except that I see we

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On Sat, Apr 12, 2014 at 02:10:13PM -0400, Jan Wieck wrote: Since it doesn't seem to produce any side effects, I'd think that making the snapshot unique within txid_current_snapshot() and filtering duplicates on input should be sufficient and eligible for backpatching. Agreed. The attached

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/13/14 08:27, Marko Kreen wrote: On Sat, Apr 12, 2014 at 02:10:13PM -0400, Jan Wieck wrote: Since it doesn't seem to produce any side effects, I'd think that making the snapshot unique within txid_current_snapshot() and filtering duplicates on input should be sufficient and eligible for

Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: [HACKERS] Problem with txid_snapshot_in/out() functionality)

On 04/12/2014 05:03 PM, Andres Freund wrote: If we don't, aren't we letting other backends see non-self-consistent state in regards to who holds which locks, for example? I think that actually works out ok, because the locks aren't owned by xids/xacts, but procs. Otherwise we'd be in deep

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/13/14 14:22, Jan Wieck wrote: On 04/13/14 08:27, Marko Kreen wrote: I think you need to do SET_VARSIZE also here. Alternative is to move SET_VARSIZE after sort_snapshot(). And it seems the drop-double-txid logic should be added also to txid_snapshot_recv(). It seems weird to have it

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/2014 12:07 AM, Jan Wieck wrote: Hackers, the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. This string is

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/14 03:27, Heikki Linnakangas wrote: On 04/12/2014 12:07 AM, Jan Wieck wrote: Hackers, the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 2014-04-12 10:27:16 +0300, Heikki Linnakangas wrote: On 04/12/2014 12:07 AM, Jan Wieck wrote: The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. This string is later rejected by txid_snapshot_in() when trying

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/14 08:38, Andres Freund wrote: Since it's sorted there, that should be fairly straightforward. Won't fix already created and stored datums tho. Maybe _in()/parse_snapshot() should additionally skip over duplicate values? Looks easy enough. There is the sort ... missed that when

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

Heikki Linnakangas hlinnakan...@vmware.com writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 2014-04-12 09:47:24 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 12 Apr 2014 08:35, Jan Wieck j...@wi3ck.info wrote: On 04/12/14 03:27, Heikki Linnakangas wrote: On 04/12/2014 12:07 AM, Jan Wieck wrote: Hackers, Hmm. Do we snapshots to be stored in tables, and included in a dump? I don't think we can guarantee that will work, at least not across

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/14 10:09, Greg Stark wrote: A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids. http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html Regards, Jan -- Jan Wieck Senior Software Engineer http://slony.info --

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 2014-04-12 11:15:09 -0400, Jan Wieck wrote: On 04/12/14 10:09, Greg Stark wrote: A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids. http://www.postgresql.org/docs/9.3/static/app-pgresetxlog.html Using that as part of any

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/14 11:18, Andres Freund wrote: On 2014-04-12 11:15:09 -0400, Jan Wieck wrote: On 04/12/14 10:09, Greg Stark wrote: A pg_restore would start a new xid space from FirstNormalXid which would obviously not work with any stored txids.

Re: [HACKERS] Problem with txid_snapshot_in/out() functionality

On 04/12/14 10:03, Andres Freund wrote: On 2014-04-12 09:47:24 -0400, Tom Lane wrote: Heikki Linnakangas hlinnakan...@vmware.com writes: On 04/12/2014 12:07 AM, Jan Wieck wrote: the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that

Re: [HACKERS] Problem with displaying wide tables in psql

Hi. I've done some corrections for printing newline and wrap indicators. Please review the attached patch. 2014-04-11 0:14 GMT+04:00 Sergey Muraviov sergey.k.murav...@gmail.com: Hi. Thanks for your tests. I've fixed problem with headers, but got new one with data. I'll try to solve it

Re: [HACKERS] Problem with displaying wide tables in psql

Looks good. It's still not doing the old-ascii column dividers but to be honest I'm not sure what the intended behaviour of old-ascii is. I've noticed old-ascii only displays the line markers for dividing lines, not the final one. That seems pretty useless and maybe it's why we switched to the

Re: [HACKERS] Problem with displaying wide tables in psql

I hope that I realized old-ascii logic correctly. 2014-04-11 19:10 GMT+04:00 Greg Stark st...@mit.edu: Looks good. It's still not doing the old-ascii column dividers but to be honest I'm not sure what the intended behaviour of old-ascii is. I've noticed old-ascii only displays the line

Re: [HACKERS] Problem with displaying wide tables in psql

Sergey Muraviov wrote: I hope that I realized old-ascii logic correctly. I don't know what you changed here, but I don't think we need to preserve old-ascii behavior in the new code, in any way. If you're mimicking something obsolete and the end result of the new feature is not great, perhaps

Re: [HACKERS] Problem with displaying wide tables in psql

There were no support for wrapping and old-ascii line style in expanded mode at all. But now they are. 2014-04-11 21:58 GMT+04:00 Alvaro Herrera alvhe...@2ndquadrant.com: Sergey Muraviov wrote: I hope that I realized old-ascii logic correctly. I don't know what you changed here, but I

Re: [HACKERS] Problem with displaying wide tables in psql

Yeah, I think I agree. I'm pretty happy to commit it without old-ascii doing anything special. It looks to me like old-ascii just isn't very useful for a single column output (like expanded mode is implicitly). Maybe that needs to be fixed but then it needs to be fixed for non expanded mode as

[HACKERS] Problem with txid_snapshot_in/out() functionality

Hackers, the Slony team has been getting seldom reports of a problem with the txid_snapshot data type. The symptom is that a txid_snapshot on output lists the same txid multiple times in the xip list part of the external representation. This string is later rejected by txid_snapshot_in()

Re: [HACKERS] Problem with displaying wide tables in psql

Ok, So I've hacked on this a bit. Below is a test case showing the problems I've found. 1) It isn't using the newline and wrap indicators or dividing lines. 2) The header is not being displayed properly when it contains a newline. I can hack in the newline and wrap indicators but the header

Re: [HACKERS] Problem with displaying wide tables in psql

Hi. Thanks for your tests. I've fixed problem with headers, but got new one with data. I'll try to solve it tomorrow. 2014-04-10 18:45 GMT+04:00 Greg Stark st...@mit.edu: Ok, So I've hacked on this a bit. Below is a test case showing the problems I've found. 1) It isn't using the newline

Re: [HACKERS] Problem with displaying wide tables in psql

Hi. How can I pass or set the value of pset variable for an regression test? The code with ioctl was copied from print_aligned_text function, which has a long history. 43ee2282 (Bruce Momjian 2008-05-16 16:59:05 + 680) if (ioctl(fileno(stdout), TIOCGWINSZ, screen_size) != -1)

Re: [HACKERS] Problem with displaying wide tables in psql

How can I pass or set the value of pset variable for an regression test? I just wrote some tests using \pset columns to control the output. Having figured out what the point of the patch is I'm pretty happy with the functionality. It definitely is something I would appreciate having. One thing

Re: [HACKERS] Problem with displaying wide tables in psql

On Sat, Feb 15, 2014 at 11:08 AM, Emre Hasegeli e...@hasegeli.com wrote: This is my review about 3th version of the patch. It is an useful improvement in my opinion. It worked well on my environment. I'm reviewing this patch. One thing to comment: With no doc changes and no regression tests

Re: [HACKERS] Problem with displaying wide tables in psql

On 2014-04-08 12:15:47 -0400, Greg Stark wrote: With no doc changes and no regression tests I was halfway inclined to just reject it out of hand. To be fair there were no regression tests for wrapped output prior to the patch but still I would have wanted to see them added. We often pare down

Re: [HACKERS] Problem with displaying wide tables in psql

On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund and...@2ndquadrant.com wrote: I don't think this is easily testable that way - doesn't it rely on determining the width of the terminal? Which you won't have when started from pg_regress? There's a pset variable to set the target width so at least

Re: [HACKERS] Problem with displaying wide tables in psql

2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@gmail.com: New code doesn't work with empty strings but I've done minor optimization for this case. It seems better now. I added some new lines and spaces, removed unnecessary parentheses and marked it as Ready for Committer.

Re: [HACKERS] Problem with displaying wide tables in psql

Thanks. 2014-02-17 12:22 GMT+04:00 Emre Hasegeli e...@hasegeli.com: 2014-02-16 18:37, Sergey Muraviov sergey.k.murav...@gmail.com: New code doesn't work with empty strings but I've done minor optimization for this case. It seems better now. I added some new lines and spaces, removed

  1   2   3   4   5   6   7   8   9   10   >