Kevin Grittner wrote:
"Joshua D. Drake" wrote:
The answer to this is:
PostgreSQL.org recommends that this setting be left on at all
times. Turning it off, may lead to data corruption.
Anything else is circumstantial and based on knowledge and facts
we don't have about environmental fact
Aftab Hussain wrote:
> Please accept attached patch for the following problem.
This patch has not been replied, but I can reproduce the error with:
=# SET timezone = 'Asia/Karachi';
=# SELECT timeofday()::timestamptz;
ERROR: invalid input syntax for type timestamp with time zone: "Tue May 11
Takahiro Itagaki wrote:
> Aftab Hussain wrote:
>
>> Please accept attached patch for the following problem.
>
> This patch has not been replied, but I can reproduce the error with:
> =# SET timezone = 'Asia/Karachi';
> =# SELECT timeofday()::timestamptz;
> ERROR: invalid input syntax for type t
Robert Haas wrote:
Please email your patch to the list (replying to this email is fine)
and add it here:
https://commitfest.postgresql.org/action/commitfest_view/open
Here's my patch, developed against HEAD, that adds the function
'xpath_exists'. The function is a lot simpler than originally
On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov wrote:
>> The referential integrity triggers contain some extra magic that isn't
>> easily simulatable in userland, and that is necessary to make the
>> foreign key constraints airtight. We've discussed this previously but
>> I don't remember which
On 2010-05-11 14:29 +0200, Robert Haas wrote:
> On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov wrote:
>>> The referential integrity triggers contain some extra magic that isn't
>>> easily simulatable in userland, and that is necessary to make the
>>> foreign key constraints airtight. We've discu
2010/5/11 Marko Tiikkaja :
> On 2010-05-11 14:29 +0200, Robert Haas wrote:
>
>> On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov wrote:
>>
The referential integrity triggers contain some extra magic that isn't
easily simulatable in userland, and that is necessary to make the
foreign
This is getting way off topic, but:
On 5/11/10 3:55 PM +0300, Nicolas Barbier wrote:
T2> SELECT i FROM a WHERE i = 1 FOR SHARE; -- Lock a with i = 1 FOR SHARE.
i
---
1
(1 Zeile)
T2> SELECT a_id FROM b WHERE a_id = 1; -- Check whether it's got
anything pointing to it.
a_id
--
(0 Zeil
2010/5/11 Marko Tiikkaja :
> This is getting way off topic, but:
>
> On 5/11/10 3:55 PM +0300, Nicolas Barbier wrote:
>>
>> T2> SELECT i FROM a WHERE i = 1 FOR SHARE; -- Lock a with i = 1 FOR
>> SHARE.
>> i
>> ---
>> 1
>> (1 Zeile)
>>
>> T2> SELECT a_id FROM b WHERE a_id = 1; -- Check whether
On 5/11/10 4:07 PM +0300, Nicolas Barbier wrote:
2010/5/11 Marko Tiikkaja:
This is getting way off topic, but:
On 5/11/10 3:55 PM +0300, Nicolas Barbier wrote:
T2>SELECT i FROM a WHERE i = 1 FOR SHARE; -- Lock a with i = 1 FOR
SHARE.
i
---
1
(1 Zeile)
T2>SELECT a_id FROM b WHERE
On 5/11/10 4:11 PM +0300, I wrote:
I took the "SELECT ... FOR SHARE" suggestion in a more general way,
suggesting the use of row-level locks. T2 should be holding an
exclusive row-level lock (SELECT ... FOR UPDATE) when checking for
references.
Hmm. Right, that transaction wouldn't see the ro
Simon Riggs wrote:
>
> Traffic on the PostgreSQL lists is very high now and I freely admit that
> reading every email is simply not possible for me, even the ones that
> mention topics that keyword searches tell me are of potential interest.
>
> If anybody knows of a bug or suspected bug in my co
On Tue, 11 May 2010, Bruce Momjian wrote:
Simon Riggs wrote:
Traffic on the PostgreSQL lists is very high now and I freely admit that
reading every email is simply not possible for me, even the ones that
mention topics that keyword searches tell me are of potential interest.
If anybody knows
Marko Tiikkaja writes:
> On 5/11/10 4:11 PM +0300, I wrote:
>> I took the "SELECT ... FOR SHARE" suggestion in a more general way,
>> suggesting the use of row-level locks. T2 should be holding an
>> exclusive row-level lock (SELECT ... FOR UPDATE) when checking for
>> references.
> Hmm. Right,
On Tue, May 11, 2010 at 3:58 PM, Marc G. Fournier wrote:
> On Tue, 11 May 2010, Bruce Momjian wrote:
>
>> Simon Riggs wrote:
>>>
>>> Traffic on the PostgreSQL lists is very high now and I freely admit that
>>> reading every email is simply not possible for me, even the ones that
>>> mention topics
Nicolas Barbier wrote:
>>> Switch to T1:
>
> 1> COMMIT; -- Commit the insertion...
> COMMIT
>
>>> T2 continues:
>
> DELETE 1
> T2> COMMIT; -- Commit the deletion of a with i = 1.
> COMMIT
> T2> SELECT * FROM b EXCEPT SELECT * FROM a;
> a_id
> --
> 1
> (1 Zeile)
>
> Woops.
On Tue, 2010-05-11 at 09:50 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> >
> > Traffic on the PostgreSQL lists is very high now and I freely admit that
> > reading every email is simply not possible for me, even the ones that
> > mention topics that keyword searches tell me are of potential
Simon Riggs wrote:
> On Tue, 2010-05-11 at 09:50 -0400, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > >
> > > Traffic on the PostgreSQL lists is very high now and I freely admit that
> > > reading every email is simply not possible for me, even the ones that
> > > mention topics that keyword sea
On May 11, 2010, at 13:29 , Robert Haas wrote:
> On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov wrote:
>>> The referential integrity triggers contain some extra magic that isn't
>>> easily simulatable in userland, and that is necessary to make the
>>> foreign key constraints airtight. We've disc
Magnus Hagander writes:
> On Tue, May 11, 2010 at 3:58 PM, Marc G. Fournier wrote:
>> Not sure where the split would be, mind you ... almost thinking about patch
>> review / discussions vs hashing out new features or something like that ...
> We just *discontinued* -patches.
Yeah, it's not tim
On Tue, 2010-05-11 at 10:23 -0400, Bruce Momjian wrote:
> Sure. You did a huge job of getting HS done and I will try to help
> where I can, and I know you have a business to run
> (http://www.2ndquadrant.com/).
2ndQuadrant is in the end the main and final reason Hot Standby exists
and has now fu
2010/5/11 Florian Pflug :
> On May 11, 2010, at 13:29 , Robert Haas wrote:
>> On Tue, May 11, 2010 at 2:16 AM, Dmitry Fefelov wrote:
The referential integrity triggers contain some extra magic that isn't
easily simulatable in userland, and that is necessary to make the
foreign key c
Heikki Linnakangas writes:
> Takahiro Itagaki wrote:
>> Should we add PKST timezone? Also, I found a list of timezones[1]
>> and we don't have 36 tznames in the list. Should we also need them?
> I don't think we want to include all timezone names in the default
> config, timezone abbreviations ar
On Fri, May 7, 2010 at 10:44 AM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of vie may 07 07:33:55 -0400 2010:
>> On Thu, May 6, 2010 at 3:29 PM, Andy Lester wrote:
>> > I was looking for how to undo a CLUSTER call earlier today. Nothing on
>> > the CLUSTER page told me how to d
Florian Pflug wrote:
> The serialization error, however, disappears if the two
> transactions are swapped. The following sequence of commands
> succeeds, even though the FK constraint is not satisfied.
>
> C1: BEGIN
> C1: INSERT INTO child (parent_id) VALUES (0)
> C2: BEGIN
> C2: SET TRANSACTIO
On May 11, 2010, at 17:04 , Robert Haas wrote:
> 2010/5/11 Florian Pflug :
>> C1: BEGIN
>> C1: INSERT INTO child (parent_id) VALUES (0)
>> C2: BEGIN
>> C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
>> C2: SELECT TRUE -- Take snapshot *before* C1 commits
>> C1: COMMIT
>> C2: DELETE FROM parent WH
Tom Lane wrote:
> Heikki Linnakangas writes:
>> Takahiro Itagaki wrote:
>>> Should we add PKST timezone? Also, I found a list of timezones[1]
>>> and we don't have 36 tznames in the list. Should we also need them?
>
>> I don't think we want to include all timezone names in the default
>> config,
Heikki Linnakangas writes:
> Tom Lane wrote:
>> I don't think that's actually it. It looks to me like the Asia/Karachi
>> zone definition expects the abbreviations to be PKST and PKDT. Not sure
>> whether PKT is really in use, but it is not sensible to add PKST by
>> itself.
> How did you come
src/tools/pginclude/cpluspluscheck says:
./utils/rbtree.h:21: error: expected ‘,’ or ‘...’ before ‘new’
Can we rename the "new" to something like "new_whateveritis"? And what
is it? :-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
On 5/11/2010 12:39 PM, Florian Pflug wrote:
On May 11, 2010, at 17:04 , Robert Haas wrote:
2010/5/11 Florian Pflug :
C1: BEGIN
C1: INSERT INTO child (parent_id) VALUES (0)
C2: BEGIN
C2: SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
C2: SELECT TRUE -- Take snapshot *before* C1 commits
C1: COMMIT
On Tue, May 11, 2010 at 1:34 PM, Peter Eisentraut wrote:
> src/tools/pginclude/cpluspluscheck says:
>
> ./utils/rbtree.h:21: error: expected ‘,’ or ‘...’ before ‘new’
>
> Can we rename the "new" to something like "new_whateveritis"? And what
> is it? :-)
It's a new value of some kind to be logic
On May 11, 2010, at 20:05 , Jan Wieck wrote:
> The problem really is that in the case of deleting a PK row while a
> concurrent transaction creates such a reference cannot be solved with user
> level visibility rules in case of a serializable transacton, unless you go
> really expensive routes.
On Tue, May 11, 2010 at 10:45 AM, Heikki Linnakangas
wrote:
> I don't think we want to include all timezone names in the default
> config, timezone abbreviations aren't always unique for example. But we
> should include PKST because we already include PKT; it would be nasty
> for an application to
Joachim Wieland writes:
> Good we have found that inconsistency now, so let's add PKST.
OK, done. BTW, I notice that PKT was labeled "(not in zic)", which
is not the case, per this discussion. I seem to recall having noticed
some others that seemed to be mislabeled the same way. What process d
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Tom Lane wrote:
> > > "Joshua D. Drake" writes:
> > > > On Wed, 2010-05-05 at 20:24 -0400, Robert Haas wrote:
> > > >> I think it will be confusing if we change the name, so I vote to not
> > > >> change the name.
> > >
> > > > Actually, I would vot
On Tue, 2010-05-11 at 14:01 +0900, Fujii Masao wrote:
> On Mon, May 10, 2010 at 3:27 PM, Simon Riggs wrote:
> > I already explained that killing the startup process first is a bad idea
> > for many reasons when shutdown was discussed. Can't remember who added
> > the new standby shutdown code rece
36 matches
Mail list logo
