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 list (pgsql-hackers@
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
> >> wrote:
> >>> I noticed a failure in the inet.sql test while running
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 forcing the
>>> parallel bitmap.
>>>
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 running the regression
>>> tests with parallelism cranked up, and can reproduce
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 interactively
>> as follows. After an spgist index is c
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 inet.sql so it was only
16 rows even wi
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 | 10.1.2.3/8
> 10.0.0.0/32
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 to
> the one shown below, the qu
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 force_parallel_mod
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 self.
General questions are b
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 w
* 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
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 this section means?
>
> Noah create
* 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 go
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 it's supposed to
be for things we th
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 pgsql-hack
* 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, pleas
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 the
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 extensions are
>> dumped individually ". That's not
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, I didn't spot that.
--
Rob
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 the access method c
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 checkExtensionMembership()
since 5d58999, an access method does not have ACLs an
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
>>> expected that when this routine is invoked
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() the object is not sele
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 -c 'CREATE EXTEN
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 > ~/tmp/bloom.sql
> createdb
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 outpu
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 applications.
> JSONB is the "
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
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')
> -- it is ok, expect
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 || '{"A":{"y":2}}'::js
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 either nobody has
>> > ever tried to use 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, no doubt.
>
> The fact that we've not heard th
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;
> > #define log_min_messages (*log_min_messages_
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 PostgreSQL headers. It won
>
>
> 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 you'r
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 global *variables*, not
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.
> >>
> > Actually, we e
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 use orafce on Windows an
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 very recently grew a
> >
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 that we've not heard this be
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 either nobody has
ever tried t
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
C:\Users\Pavel\orafce-VERSION_3_1_2\orafc
Thom Brown 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 read/write
On 14 June 2015 at 04:25, Michael Paquier wrote:
> On Sun, Jun 14, 2015 at 11:38 AM, Thom Brown 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 beha
On Sun, Jun 14, 2015 at 11:38 AM, Thom Brown 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 (transformIndexConstraints
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 (
On Thu, May 15, 2014 at 10:38 AM, Andres Freund wrote:
>> . 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. That'll break with this
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 seems
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
> before
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 */
+ AtAbort_Twophas
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 m
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 vx
On Tue, Apr 29, 2014 at 2:52 AM, Peter Eisentraut 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 mailing list (pgsql-
rebased
2014-04-29 7:43 GMT+04:00 Michael Paquier :
> On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
> wrote:
> > 2014-04-29 5:52 GMT+04:00 Peter Eisentraut :
> >
> >> Please fix this compiler warning. I think it came from this patch.
> >> print.c: In function 'print_aligned_vertical':
> >>
On Tue, Apr 29, 2014 at 12:37 PM, Sergey Muraviov
wrote:
> 2014-04-29 5:52 GMT+04:00 Peter Eisentraut :
>
>> 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
>>
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: note
Greg Stark 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
run in some o
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
Greg Stark 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 alternate output
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
On 2014-04-14 13:47:35 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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 a bad idea. Could
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 n
Heikki Linnakangas 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 locks earlier, befor
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 committe
On 04/12/2014 05:03 PM, Andres Freund wrote:
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
Heikki Linnakangas 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 o
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
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 PostPr
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 beh
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 trou
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
bac
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 attach
On 04/12/14 10:03, Andres Freund wrote:
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
Heikki Linnakangas 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 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.
>
http://www.postgresql.org/docs/9.3/static/app-pgres
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 pa
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
--
S
On 12 Apr 2014 08:35, "Jan Wieck" 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
>
On 2014-04-12 09:47:24 -0400, Tom Lane wrote:
> Heikki Linnakangas 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
> >
Heikki Linnakangas 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 the external repr
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 glanci
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
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
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 la
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() whe
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 wel
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 :
> 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
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 t
I hope that I realized old-ascii logic correctly.
2014-04-11 19:10 GMT+04:00 Greg Stark :
> 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
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 new
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 :
> 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
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 :
> 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 "wra
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
> 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
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)
201
On Tue, Apr 8, 2014 at 12:19 PM, Andres Freund 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 the
formatting code
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 do
On Sat, Feb 15, 2014 at 11:08 AM, Emre Hasegeli 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 I was halfway in
Thanks.
2014-02-17 12:22 GMT+04:00 Emre Hasegeli :
> 2014-02-16 18:37, Sergey Muraviov :
>
> > 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
2014-02-16 18:37, Sergey Muraviov :
> 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".
fix_psql_print_aligned_vertical_v5.pat
1 - 100 of 1070 matches
Mail list logo
