On Sun, 2014-01-19 at 15:31 +0100, Stefan Kaltenbrunner wrote:
> > /* followings are for client encoding only */
> > PG_SJIS,/* Shift JIS
> > (Winindows-932) */
>
> while you have that file open: s/Winindows-932/Windows-932 maybe?
done
--
On 2014-01-23 11:50:57 -0500, Robert Haas wrote:
> On Thu, Jan 23, 2014 at 7:05 AM, Andres Freund wrote:
> > I don't think shared buffers fsyncs are the apt comparison. It's more
> > something like UpdateControlFile(). Which PANICs.
> >
> > I really don't get why you fight PANICs in general that m
On Thu, Jan 23, 2014 at 7:05 AM, Andres Freund wrote:
> I don't think shared buffers fsyncs are the apt comparison. It's more
> something like UpdateControlFile(). Which PANICs.
>
> I really don't get why you fight PANICs in general that much. There are
> some nasty PANICs in postgres which can ha
Hi,
On 2014-01-22 13:00:44 -0500, Robert Haas wrote:
> Well, apparently, one is going to PANIC and reinitialize the system.
> I presume that upon reinitialization we'll decide that the slot is
> gone, and thus won't recreate it in shared memory.
Yea, and if it's half-gone we'll continue deletion.
On Wed, Jan 22, 2014 at 10:48 AM, Andres Freund wrote:
> Yes, individual operations should be, but you cannot be sure whether a
> rename()/unlink() will survive a crash until the directory is
> fsync()ed. So, what is one going to do if the unlink suceeded, but the
> fsync didn't?
Well, apparently
On 2014-01-22 10:14:27 -0500, Robert Haas wrote:
> On Wed, Jan 22, 2014 at 9:48 AM, Andres Freund wrote:
> > On 2014-01-18 08:35:47 -0500, Robert Haas wrote:
> >> > I am not sure I understand that point. We can either update the
> >> > in-memory bit before performing the on-disk operations or
> >>
On Wed, Jan 22, 2014 at 9:48 AM, Andres Freund wrote:
> On 2014-01-18 08:35:47 -0500, Robert Haas wrote:
>> > I am not sure I understand that point. We can either update the
>> > in-memory bit before performing the on-disk operations or
>> > afterwards. Either way, there's a way to be inconsistent
On 2014-01-18 08:35:47 -0500, Robert Haas wrote:
> > I am not sure I understand that point. We can either update the
> > in-memory bit before performing the on-disk operations or
> > afterwards. Either way, there's a way to be inconsistent if the disk
> > operation fails somewhere inbetween (it mig
On 01/18/2014 02:31 PM, Robert Haas wrote:
> On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote:
>> Anybody who actually uses SHIFT_JIS as an operational encoding, rather
>> than as an input/output encoding, is into pain and suffering. Personally
>> I'd be quite happy to see it supported as clie
Robert Haas writes:
> On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote:
>> Anybody who actually uses SHIFT_JIS as an operational encoding, rather
>> than as an input/output encoding, is into pain and suffering. Personally
>> I'd be quite happy to see it supported as client_encoding, but forbi
On 01/18/2014 09:31 PM, Robert Haas wrote:
> On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote:
>> Anybody who actually uses SHIFT_JIS as an operational encoding, rather
>> than as an input/output encoding, is into pain and suffering. Personally
>> I'd be quite happy to see it supported as clie
On Thu, Jan 16, 2014 at 9:54 AM, Andres Freund wrote:
>> Maybe it would be better to get rid of active/in_use and have
>> three states: REPLSLOT_CONNECTED, REPLSLOT_NOT_CONNECTED,
>> REPLSLOT_FREE. Or something like that.
>
> Hm. Color me unenthusiastic. If you feel strongly I can change it, but
On Thu, Jan 16, 2014 at 10:15 PM, Craig Ringer wrote:
> Anybody who actually uses SHIFT_JIS as an operational encoding, rather
> than as an input/output encoding, is into pain and suffering. Personally
> I'd be quite happy to see it supported as client_encoding, but forbidden
> as a server-side en
On 01/16/2014 02:28 AM, Robert Haas wrote:
> - If you address /* FIXME: apply sanity checking to slot name */, then
> I think that also addresses /* XXX: do we want to use truncate
> identifier instead? */. In other words, let's just error out if the
> name is too long. I'm not sure what other san
Hi,
On 2014-01-16 09:34:51 -0500, Robert Haas wrote:
> >> - ReplicationSlotAcquire probably needs to ignore slots that are not
> >> active.
> > Not sure what you mean? If the slot isn't in_use we'll skip it in the loop.
>
> active != in_use.
>
> I suppose your point is that the slot can't be in
On Wed, Jan 15, 2014 at 3:39 PM, Andres Freund wrote:
> On 2014-01-15 13:28:25 -0500, Robert Haas wrote:
>> - I think you should just regard ReplicationSlotCtlLock as protecting
>> the "name" and "active" flags of every slot. ReplicationSlotCreate()
>> would then not need to mess with the spinloc
Hi,
On 2014-01-15 13:28:25 -0500, Robert Haas wrote:
> - I think you should just regard ReplicationSlotCtlLock as protecting
> the "name" and "active" flags of every slot. ReplicationSlotCreate()
> would then not need to mess with the spinlocks at all, and
> ReplicationSlotAcquire and Replication
Review of patch 0002:
- I think you should just regard ReplicationSlotCtlLock as protecting
the "name" and "active" flags of every slot. ReplicationSlotCreate()
would then not need to mess with the spinlocks at all, and
ReplicationSlotAcquire and ReplicationSlotDrop get a bit simpler too I
think.
This 0001 patch, to log running transactions more frequently, has been
pending for a long time now, and I haven't heard any objections, so
I've gone ahead and committed that part.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
19 matches
Mail list logo
